Labview 8.2 variants are completely different! They no longer contain their size in the first 4 bytes!

[TCPlomp]

Here's what I mean


Ton

Message Edited by TonP on 04-23-2007 06:17 PM

[billings11]

Oh good, that's one way you could do it.  I would still have to go in to the NI database toolkit and change every instance of flatten to string to use the 7.1 type.  Just so you know, this is not selected in the database toolkit, so the variant type does not work for 8.2 at all the way the database connectivity toolkit is being shipped.  Then I will have to repackage the database toolkit as a distribution and replace the NI version with my own modified version at 7 computers.  Since my company purchased the toolkit and this is NI's bug, I really think NI should fix this and ship me a new distribution of the database toolkit.  

I also am worried about this as a long-term solution.  How long will NI maintain that option to flatten to data strings as they were in 7.X?  Will that option still be around in Labview 9?  There must be a better way to extract the data size than convert it back to the 7.X string.  Isn't there a way to pull it from the 8.X string?  What is the difference between 7.X and 8.X?  Why would the flattened strings come out completely different?  Does it have to do with the new "little-endian/big-endian" options?  Shouldn't the "Prepend Array or String Size" option just prepend the size for any data type instead of just arrays or strings?  Is there any documentation about what changed?

[billings11]

I am just very concerned about this because I have mountains of data stored in our database from labview 7.X executables.  So if there is a major difference between the structure of data types between one version of labview and another, it could potentially make anything I saved in 7.X totally unusable in some other version.  Luckily, it looks like the 7.X data coming out of my database is being converted to labview 8.2 data types properly through the variant to data function.  That function must have been modified for 8.X to work properly for both 7.X and 8.X variant types.  It's just the saving part that broke in the database connectivity toolkit.  But the fact that NI would change the "guts" of an important datatype without telling anyone is scary.  So I want to know what changed, why it changed, and what are NI's plans going forward.  And the fix you show means I would really be continuing to save data to my database in the old format, that I have to hope NI will keep supporting that old 7.X variant type forever in the variant to data function.  It is just very fructrating to be kept in the dark about it.

[TCPlomp]

Ahhh,

now I get where your problem comes from!
You stored the actual variant inside the DB (maybe I didn't read your Q's thouroughly).

I wouldn't ask how long NI is going to support the back read option. The typecast function still can typecast 4.x data (when a boolean array was made up of bits instead of bytes).

What you could do is some scripting to set all the functions to 7.x OR do a batch conversion on your DB (eg. read as 7.x save a 8.x)

Ton

[billings11]

Ton,

Thanks for your support.  Yes I am saving variants directly into my database in image or OLE object fields. 

Of course I can't do a batch conversion to my database data because it is impossible to save 8.X variants to the database right now!  Right now you can only save a 7.X variant to a database because you have to use the fix you suggested to flatten it to a 7.1 string!.  The 8.X variant cannot be saved to a database.

[billings11]

Also, while the vi I attached (Flatten to String) allows you to flatten to the 7.X version, the actual vi in the Database Connectivity Toolkit is different.  That one is called "Variant To Flattened String" and is a different function that does the same thing.  Variant To Flattened String does not let you select the 7.X type, but Flatten To String does.  So I will have to not only select this 7.X option, but actually replace every instance of "Variant to Flattened String" with "Flatten to String".

The examples attached now show how it is actually implemented in the database toolkit.

[billings11]

Unfortunately Ton's fix will not work to fix the database connectivity toolkit because Variant to Flattened String actually does something very different than Flatten to String.  I did not realize this at first, and used Flatten to String in my example.  But it is necessary to use Variant To Flattened String because it results in a data type descriptor array that is necessary to drive the parsing in the toolkit.  So we are back to square 1.

Attached is the accurate representation of what happens in the database connectivity toolkit.  You input a cluster of multiple datatypes.  When it gets to the variant datatype it grabs the first four bytes as the size.  So it is actually a cluster containing a variant that it is handling.

Message Edited by billings11 on 04-23-2007 03:28 PM