Mar 29, 2014

Long story short - the problem I was hitting with C# was neither in Windows RT, nor in OneSql.Client. So I’m back on my way to implement the necessary test automation.

Meanwhile, I discovered a product bug – OneSql Client misses the end of the result set when multiple rows are read at a time. While I’ve fixed this bug already, I’ll hold off a bits update. The workaround for this bug is to read rows one by one. If this is a problem for any of the current adopters, please let me know via email at zlatko+onesql@michailov.org.

Mar 21, 2014

I’ve been testing OneSql.Client using a JavaScript app assuming that if it works for JavaScript, it should work for C# as well since OneSql.Client is written in C#. I’ve been wrong.

I recently discovered that OneSql.Client doesn’t function properly when it’s hosted by C# apps. I’ve narrowed the problem down to the platform’s StreamSocket. I posted a question on the C# Apps forum, but nobody from the product team has responded yet. I have little hope anybody will ever respond.

This is very unfortunate, because C# represents a large portion of the Windows Store apps. Also, I still plan to implement the necessary test automation using C# in order to gain sufficient confidence in the quality of the product.

I first apologize to all of the adopters who can’t use my product in their C# apps. I should have tried C# before announcing the alpha releases.

I’m asking you for clues how I should be initializing/using StreamSocket to make it behave like it does in JavaScript apps. I admit I’m not certain whether the platform classes are exactly the same for JavaScript apps and for C# apps. I also suspect there might be differences in the threading models that I haven’t seen documented. Any other clues are also welcome.

New in 0.2

This release fixes the error reporting model. I had noticed the WinJS app was not getting errors when I released 0.1. I thought I was doing something wrong that could be easily fixed. It turns out the WinRT interop layer can only surface a single HRESULT value from a component to a WInJS app, i.e. the exception instance – its type, message, stack, etc. is lost.
To fix that WinRT deficiency, I had to replace throwing exceptions with raising custom errors. That is now done through a special Error object that is exposed on both SqlClient and TdsClient. An app has to examine that Error property upon a promise error. The Error object contains a Code and a Message properties.

Next

Notice that this release is still “alpha”. It will remain like that until I have a sufficient coverage through test automation. That is the next thing on my list.
I will appreciate feedback. Please send email to zlatko+onesql@michailov.org.