Write classes with connectivity toolkit

[reformedView]

Messing around with the connectivity toolkit.  Is there a way of writing a class object to a database?

[a_clucker]

Hi reformedView,

Please have a look at this Database Connectivity Toolkit manual: http://www.ni.com/pdf/manuals/371525a.pdf. In chapter 4, it goes over data types. It looks like there isn't anything specfic to a class object, but you might be able to try and save it as binary. However, this could cause errors when decoding the objects on the other end, especially if the object contains any variably-sized data, e.g. dynamic arrays.

Another approach you could take is to have a DB table for each object, and then just save the object's parameters into their own table fields.

[Zwired1]

Help me.  OO noob. What does "saving a class object" mean?  If it's saving the cluster, could you flatten to XML and save that as text?

[reformedView]

The cluster is private data. You can iterate through it and save the elements individually by casting it to a variant and then runnning it through "Get Variant Data" with Type set to an array of variants.  However, I am interested in what you would do if, say, one of the elements was itself a LabVIEW class.  I think I am going to do something as was suggested above, store the internal class in its own table and provide the owning class a reference to it -- its table and id, perhaps.  This seems to conform more to standard DB "foreign key" practice anyway.

[Kyle97330]

I would use the "Flatten to String" and "Unflatten from string" from the Numeric->Data Manipulation palette, if you don't need any program other than LabVIEW to ever read it.  With LabVIEW classes it's smart enough to not write any non-default values, and it's version controlled so even if you update your class to add or remove an element in the private cluster it will still load it OK.  

"Flatten to XML" and "Unflatten from XML" in the File I/O->XML->LabVIEW Schema palette work also, but the cost of the overhead from XML makes the data 3 to 100 times bigger in my experience, depending on how many default values you use.  You could also read those from other non-LV programs with some fairly standard parsing...