When using the Database Connectivity Toolset, reads and writes with long binary fields are incompatible.

[cpuwzd]

I am trying to write LabVIEW Variants to long binary fields in a .mdb file using the Database Connectivity Toolset. I get errors when trying to convert the field back to a variant after reading it back from the database.

I next tried flattening the variant before writing it and ultimately wound up doing the following experiments:

1) If I use DB Tools Insert Data to write an ordinary string and read it back using a DB Tools Select Data, the string is converted from ASCII to Unicode.

2) If I use DB Tools Create Parameterized Query to do an INSERT INTO or an UPDATE operation, specifying that the data is BINARY, then read it back using a DB Tools Select Data,
the length of the string is prepended to the string itself as a big-endian four-byte integer.

I can't think of any way to do a parameterized read, although the mechanism exists to return data via parameters.

Presuming that this same problem affects Variants when they are written to the database and read back, I could see why I get an error. At least with flattened strings I have the option of discarding the length bytes from the beginning of the string.

Am I missing something here?

[David Duffey]

You'll want to use the "unflatten from string", which will automatically strip the sring length from the beginning for you.

This would allow you to flatten/unflatten and store any LabVIEW datatype to your database.

[cpuwzd]

David,

You've missed the point. When a data item is flattened to a string, the first four bytes of the string are expected to be the total length of the string in big-endian binary format. What is happening here is that preceding this four-byte length code is another copy of the same four bytes. If an ordinary string, "abcdefg" is used in place of the flattened data item, it will come back as <00><00><00><07>abcdefg. Here I've used to represent a byte in hexadecimal notation. This problem has nothing to do with flattening and unflattening data items. It has only to do with the data channel consisting of writing to and reading from the database.

I am attaching three files that you can use to demonstrate the problem. The VI file c
ontains an explanation of the problem and instructions for installing and operating the demonstration.

Ron Martin