Fixed error handling to prevent crashing ruby in 0.6.x
Allow Support for 31+ Character Usernames/Passwords
Support an optional environment variable to find FreeTDS.
…to allow for longer usernames based on tds version
Observed errors included: - Segmentation fault - cfp consistency error - object allocation during garbage collection phase These errors manifested themselves most consistently when a SQL error occurred while using threads, but would also happen occasionally without threads being involved. With TinyTds 0.6.0 changes were made to make the C code properly release the Global VM Lock (GVL) so that other threads could run while FreeTDS was waiting for results from the server (blocked on I/O). While this lock is released it is not possible to safely call the ruby C API. The way that FreeTDS deals with error messages is to define a handler to process the message when it is raised. The issue is that the error handler that TinyTds uses invokes the ruby C API to throw an exception. This accidental use of the ruby C API while TinyTds did not have the GVL caused various catastrophic conditions in the ruby VM. These conditions manifested themselves as the various error messages listed above. To fix these errors, the userdata struct is used to track if the client is currently "nonblocking" and thus does not have the GVL. In those situations, any errors are saved into a new tinytds_errordata struct that saves all necessary information. Once the GVL is re-obtained, TinyTds uses the information in the tinytds_errordata struct to throw an exception. To further complicate the issue, FreeTDS will send multiple messages/ errors if the error is severe enough. Normally, when exceptions are raised immediately, the developer will properly receive the first, detailed, message. However, when TinyTds does not have the GVL and the error is stored for later use, FreeTDS has the opportunity to send more messages, causing the first one to be overwritten with something more generic. Because of this, as soon as the first message is captured, all further messages are ignored until TinyTds::Client.execute() is called again.
Wrap dbsqlok, dbsqlexec, dbresults, and dbnextrow in rb_thread_blocking_region.
treat connection read error as connection being closed
Remove unused variable
Add Windows note to README