Improvements to GetColumnValue#9
Conversation
Still need to (a). return the value as a Buffer rather than a string (b) support other types (c). refactor so that it is not duplicating ODBC::GetColumnValue needlessly.
Keep up to date
* Return Buffer for varbinary columns
* Fix SQL_T macro for compile-time string concatenation
* Fix DEBUG_PRINTF usage in ODBCConnection::Query not respecting UNICODE
flag
* Pass 3rd argument to Query callback ("more")
* Start work on GetColumnValue returning data types probably (probably
should just use ODBC::GetColumnValue somehow - needs refactoring)
* Add ODBCResult::GetColumnValueSync
Remove strptime, use SQL_TIMESTAMP_STRUCT and mktime/_mkgmtime similar to *nix.
The Windows ODBC Driver Manager returns SQLSTATE 01S00 whereas unixODBC returns SQLSTATE IM002.
MSSQL's datetime type has only 3 millisecond precision (datetime2 supports better precision, but is unlikely to exist elsewhere)
Precision again.
MSSQL requires N'☯ąčęėįšųūž☎áäàéêèóöòüßÄÖÜ€ шчябы Ⅲ ❤' but sqlite doesn't support national character literals. Relying on default collation being unicode-capable is also non-standard, however...
See commit #c0cbf24d5dc1ccf62314e949532acc530cbe45b0
Was printing a not-necessarily-null terminated buffer with %s.
Split into GetCColumnType, GetColumnData, and ConvertColumnValue to allow ODBC::GetColumnValue (async) to do the data-getting on the worker thread and the conversion in the callback on the V8 thread. Returns a Buffer if the data type of the column is SQL_BINARY or SQL_VARBINARY. Converts the 'bit' data type into true/false using the SQL_C_BIT data type rather than SQL_C_TCHAR.
Handle null terminators got from SQLGetData with SQL_C_TCHAR Also fix exception handling in some functions
Allow fetching entire value in async mode (loops via uv_queue_work) - refactored ODBC::GetColumnValue again to make this possible without unduly duplicating code. Allow not passing maxBytes to result.getColumnValue.
TODO: Fix behaviour of maxBytes for strings (should really be maxChars), maxBytes is pretty useless for strings when you don't know if the underlying representation is unicode or utf-8.
Caused by FetchMoreData not passing on SQL_NULL_DATA
Conflicts: src/odbc.cpp - preferred my changes over upstream (since I have refactored GetColumnValue) src/odbc.h - reverted my changes to DEBUG_PRINTF src/odbc_result.cpp
…string * Handle SQL_DATE and SQL_TIMESTAMP separately
|
Awesome! Thank you for re-working this onto v0.6.11. When I get a chance to understand this in more detail and test on Linux with FreeTDS, Sqlite, MySQL and Postgres I'll probably publish it as v0.7.0 because of the compatibility changes you mentioned. |
|
Is your Windows environment 32 or 64 bit? |
|
I'm building on a 64-bit machine, but my Node.js version is 32-bit at the moment. It's possible I've introduced some changes which break 64-bit compatibility - I apologise if that's the case :( |
|
No worries. I just could not build because the call to At any rate, I got it to build but with lots of failing tests. :( Possibly because I didn't really pay close attention to what I was doing as explained above. ;) |
…timestamp because they cmoe through as SQL_DATE (just go back to treating everything as a date and time, since JavaScript doesn't care anyway whether there was originally a time component or not) (cherry picked from commit fb76807)
|
Hopefully I should have time tomorrow to fix the break I introduced for 64-bit Linux builds and do some more thorough testing with the msodbcsql11 driver. |
|
OK. Sounds good. I've been slammed with non-related work, so I haven't had much time to address any of the pull requests. :( |
|
OK, I'll need to test this further, but I that seems to work. I had to also change the buffer-reading code for integers to expect |
…les dates before 1970 correctly, unlike MSVC's _mkgmtime32). (cherry picked from commit d244a98)
|
Just added another fix - I noticed that date values before 1970 weren't being handled correctly in Windows (it was always returning |
…efine by not using TzSpecificLocalTimeToSystemTime in that case.
Fixing both an SQL_FLOAT issue and boundRow garbage Data Fixes wankdanker#67 Fixes wankdanker#8
2 participants
I've had a chance to merge the changes from 0.6.2 to 0.6.11 into my fork. I'm currently testing it myself.
There are some compatibility changes:
SQL_TYPE_DATEcolumns are handled (I don't think they were before)mktimeand_mkgmtime32SQL_BINARYcolumns are returned as a nodeBufferobject, rather than a hex-encoded stringSQL_BITcolumns are handled using theSQL_C_BITdata type rather than converting toSQL_C_CHARODBCResultfetch mode can now beFETCH_NONE, which specifies that the columns will be fetched manuallySQL_VARCHARandSQL_BINARYcolumns can be partially requested using themaxBytesparameter.I'd like to implement sending node
Bufferobjects forSQL_BINARYparameters, but I haven't yet had the time.It's not been thoroughly tested, especially on platforms other than Windows/MSSQL, so there may certainly be issues there. I don't have any other platforms set up, so I can't currently test it on those without a lot of work.