RSSQL API Coding fun

There’s a strangely satisfying feeling when I manage to get the RSSQL API to work. It’s only half documented and written for c++. I’ve never yet had to use the parts that are documented and I use c#.

Its a sad confession, but I have never written c++, I can cope with C, and I consider C# to be one of the cleanest languages to use, but c++ and I never got along. I’d like to claim I objected to the implementation of objects, or point to the over use of pointers, but the simple truth is nobody ever paid me to learn it. I have no pride and will code in any language the client asks me to use. However, without a project I don’t have the enthusiasm required to really get a handle on the language.

The problem with using .net to interface onto the API is I need to define every record layout byte by byte. Added to the fact that RSSQL programmers use every form of INT from tiny – big, plus they define a new alias for the type, making it really fun to translate.

However, enough whining, because once I crack the record structure, I then get to fight the internal integrity checks. Nothing better than watching procedure lines through the profiler to ascertain where the error is kicking out!

The latest set of mods were to update records received as web requests over the ONeil bridge. I’m extracting the detail lines to consolidate them into single orders based upon more complex rules than ONeil allows me to use.

Extracting the records proved easy enough, but going back to update the status and work order details onto each line gave me issues.
All now cracked and working sweetly.

Maybe I should publish the records I currently have defined to use the RSSQL API? I’ve done work orders, work order line, Web order details, and items. If anybody wants to have them, drop me an email and I’ll fire them over. Obviously, you have to remember, these can be different on every dot release of the product and rarely survive a full version number increment.

ONeils API – Moving to version 5.01

I do quite a lot of programming work around the edges of ONeil RS-SQL records management system. I write reports and process data extracts using SQL tools like reporting services, or integration services.

However, there is one job that comes up every couple of years.
Aligning the old code to the new API.

I was never a c++ programmer. I skipped from C, to C# without hitting that awful thing in the middle.

Things always change. The original code, used unmanaged memory and literally byte arrays to pass data. So, when a record grew a new field, the required bytes had to be aligned.

This time around they’ve changed the way the login process works, but forgotten to include this code in their API examples.

If you’re using the ONeil API for using the old unmanaged methods, you’re really going to need this:
namespace ONeilSoft.RSSQLAPI
public class APIImports
#region Login\free\get last error
[DllImport(“RSSQLAPI.DLL”, CharSet = CharSet.Unicode, ExactSpelling = true, CallingConvention = CallingConvention.Cdecl)]
public static extern UInt32 RSSQLClientLogin(
string userCode,
string userPassword,
string recordCenterGuid,
string loginOptions,
string configServer,
string configDatabase);

New style / Managed

I have to say, the new style code is looking much better. Unfortuantely, there are still some gaps in the functions available, but it really is now in the realms of normal human programming.

Sales Reporting How complex should it be?

I’ve spent years providing sales reports from databases. We went through inch thick wads of music paper with columns of numbers, we tried BI with dice and slice, drill down cubes and animated graphs.
The end result is, that I am convinced 99% of it is a waste of time. Whilst this stuff might be great for IT savvy managers, or for Information Engineers, it is invariably too much for the sales person to consume.
Possibly its ‘horses for courses,’ but I’ve not yet met the sales person on the road who wants to drill down into their data. (Please, email me, tell me you are the person who only makes his figures because of a multi-dimensional cube!)
A client recently came up with the idea of producing the most simple report they could. Four lines on a bar chart, with values as the labels. Year To Date (YTD), and Period, Actual and Budget.

The report is sent every day and the budget accumulates a daily proportion.
Of course, I’m always happy to discuss reporting and provide anything the client wants, but really ask the question: what can the sales force genuinely use?

SQL Reporting Services parameter memory

The great thing about Google is the way you can find a way to do just about anything.

I’ve been using SSRS for quite a time and haven’t had this request, but as people expect things to be so much more intuitive these days, it seems logical for a reporting system to remember what they typed last time.

I found I had to combine techniques from a couple of sites as this one says it will only cope with up to 32 entries and I had a few thousand to handle.

I’m selecting from an account number list and originally this used a long human readable code rather than a foreign key. This burst the size of reporting parameter passing and the SQL string limit. Luckily, I could painlessly convert to the unique ID.

So, I claim no original work in this, I used this link to get the basic logic functions to work.

I found the spit function on another site. The guy claimed to have written it 6 years ago.

I opted for creating a separate database to store the reporting memory. It’s a third party app and they might get upset if they found new tables appearing. I toyed with the idea of adding database and server name into the options, but decided it wasn’t a problem today and might never be.

The only issue here was the dim gotcha that the split function I’d opted to use had the parameters the other way around to purple frog’s. Took a few minutes of head scratching on that one Doh!

Works like a charm.

Thanks to the two people who did all of the hard work.

Flattening data for the end user

SQL databases are usually big complex beasts. An end user knows they have the information in the system, but it often proves too complex to extract it in a useable form.

We can use a number of tools to provide a company with data in a form they can use.

What do I mean by “flattening” the data?

A database designer works to “normalise” a database. This means removing any repeating data from a table and placing it in its own table.

For example a stock record:

Stock Code
Stock Description
Stock Category
Stock Category Description
Stock Category Discount Level
Stock price


Would be normalised into two tables:

Stock Code
Stock Description
Stock Category Code
Stock price


Stock Category Code
Stock Category Description
Stock Category Discount Level


By “joining” these two tables, they can appear as one, but when a change is required on a discount level, only one record needs to be amended, instead of all of the stock table.

This is a simple example, but it highlights the most frequent issue facing an amateur report writer. “How can I include the details from both tables on a single report?”

We would ask if the report writer needs to know how? If we provide a “view” of the data, we can offer the report writer the data joined correctly and displaying the fields they need.