New in 0.3

The most significant addition to the OnceSql Client project is the test suite. The entire source code of the test project has been released. I may be used as samples.

There are no new features in this release. Various bugs were discovered and fixed during the course of adding test automation.

There are two breaking changes:

The timeout options have been removed. This is an API change that may require changing existing app code. Otherwise it may not compile. And of course, tasks that used to time out, no longer do so.

Service DONE sections are no longer exposed to apps. This is a behavior change. It will not prevent existing app code from compilation, but you may have to remove any SqlClient.MoveToNextResultAsync() calls you have added to skip over those “unwanted” results.

Next

The “beta” label will be removed when all of the following conditions are met:

The beta release has been available for at least 1 month, i.e. no earlier than May 27, 2014.

There are at least 100 downloads of a single beta package on NuGet.

All customer-reported issues for which there is no viable workaround have been fixed.

Support

All support content will continue to be published at this blog. This link http://bit.ly/1khQm90 queries OneSql Client content.

The recommended source, however, is https://twitter.com/@OneSql where along with references to blog posts, you’ll also find short status updates and news.

Apr 18, 2014

Summary

The following properties of type OneSql.Client.Options have been removed:

ConnectTimeout

CommandTimeout

DefaultConnectTimeout

DefaultCommandTimeout

OneSql Client operations will complete only based on [MS-TDS] protocol flows, not based on any timeout.

Version

0.3 and above.

Details

The purpose of timeouts is to give control back to the app when an operation takes too long to complete. This is mainly useful in synchronous API where the client thread is blocked on the operation.

In asynchronous API, like OneSql Client, the calling thread is never blocked. It is a developer’s choice whether to await the completion of the operation or to perform some other action.

The purpose of the timeout options was to provide a “timed await” mechanism that is common for all languages.However, the current implementation is incorrect – it leaves the SqlClient (and its underlying TdsClient) in a state that prevents further usage.

The cost of cleaning up SqlClient’s state exceeds the value of the feature by far. Moreover, that cleanup (which involves a new request to the server as well as receiving its response) may take a time that is long enough to defeat the purpose of the timeout. Therefore, timeouts have been discontinued.

When you get control before the operation has finished, the SqlClient will be in a dirty state. You won’t be able to continue using it. Dispose of it. Any uncommitted transactions will be rolled back. Create a new SqlClient, connect it to the SQL Server, and decide how to continue.