December 19, 2011 at 8:59 am
Hello All,
I have created a set of C# CLR Functions that compresses data (using a GZipStream) sent to the Client Application (as SqlBytes) and this works well with a test client application written in C#.
But the main application that is to use these Functions is written in C++ and uses the Native ODBC Drivers on Windows, FreeTDS on Unix and the ZLib compression library for its Compression and Decompression.
However, the ZLIB decompressor in the C++ application can't decompress the SQLCHAR[] returned by SQLGetData (invalid header check). But it can decompress it when it is fed a file created by the very same C# CLR Function!
Also, I created a ZLIB compressed file which came out at 9K and returned this file using:
DECLARE @File AS VARBINARY(MAX) ;
SELECT @File = (SELECT * FROM OPENROWSET (BULK N'C:\Users\Public\Documents\test.xml.gz', SINGLE_BLOB) AS VARBINARY(MAX)) ;
SELECT @File ;
This 9K file is then 'bloated' to 32K when extracted using SQLGetData but when saved to disk it is still recognised as a .gz compressed file, but remains un-decompressable using the ZLIB decompressor in the application!
Can anyone shed some light on this, as I am seriously confused with it all.
Your help would really be appreciated.
--
Bob
December 19, 2011 at 11:12 am
SQLChar is unicode character. CLR String is unicode, but the file you create probably isn't unicode.
Sounds like the problem is not being aware of what is unicode and what isn't.
The probability of survival is inversely proportional to the angle of arrival.
December 19, 2011 at 1:06 pm
sturner (12/19/2011)
SQLChar is unicode character. CLR String is unicode, but the file you create probably isn't unicode.Sounds like the problem is not being aware of what is unicode and what isn't.
Hi
The files created by the CLR are not the issue here as files created with the CLR can be decompressed with the ZLIB and vice versa. The issue here is something to do with either the way the Native Driver (SQL Server Native Driver 10) deals with what is sent by the CLR procedure or what the CLR is actually sending.
When the CLR functions are used with a C# application it works but this uses a different driver. But when used with the Native ODBC driver it doesn't work!
--
Bob
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply