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.