We are currently working on implementing synchronization using the MobiLink (v12) .NET direct row handling API for multiple platforms, and there is an issue that we are experiencing with SQL server. When handling varbinary(n) columns, the data returned from the provided DBConnection appears to always be a byte array of size n, despite the actual size of the value in the consolidated database. The varbinary(max) columns appear to be working, as long they are at the end of the select statement (see related post).
One specific example we are seeing involves a column defined as varbinary(255), which contains a value that is actually 20 bytes in length. When we query the consolidated using the MobiLink .NET API, we get back an array of 255 bytes. The first 20 bytes are the actual bytes stored in the database, and the remaining bytes in the array are all zeros. If I query the data using an ADO.NET OdbcConnection pointed at the same DSN, I get the expected 20 bytes.
Is this a bug with the ODBC wrapper within the MobiLink .NET direct row handling API, or is there some way to avoid having the binary data padded with zeros?
After futher testing, it appears this may be a problem on all three platforms that we are targeting (SQL Anywhere, Oracle, and MS SQL Server)
This has now been fixed. The fix should be available in v1201 build 3752 or greater.
answered 20 Jun '12, 17:11
i'm not sure why you're seeing 0's instead of spaces, but MS SQL, using ODBC, always returns a fixed length string.
answered 14 Apr '12, 10:15