Improving Code: Programmatically building a cluster than can be

[LAVA 1.0 Content]

I am looking for suggestions on how this coding approach can be improved. I want to programmatically build a cluster of arrays than can be later unbundled by name.

The way the cluster is populated is by first reading a database Table and listing all the columns within that Table. The column contains elements of various types, that will be handled properly and not be part of this particular exercise.

The challenge is that I have access to the column names (they are in the columns array). The column information contains the types for each column (let's not pay attention to this now). In the attached image, pretend that PARTNO(n) are different names of columns. Let's also pretend every element in the database table is of the same type.

Instead of duplicating the code n-times for PARTNO's, I'd rather put the 2D Variant array (entire dataset) to a For Loop, where I can extract every element of each column and store them into their own arrays. So an array of PARTNO, another array of PARTNO 2, and so on.

However, at the bundle into array, I want to wire it in such a way that I can unbundle by name later. So the databse cluster would contain the name of the column where the data originated from. That way, a sub-vi can access the element array by unbundling by name. Simple. Plus the idea is that this can be used for any database with any column names and the end result would be the same, a cluster of arrays that can be indexed by name of the column which it originated from.

Hope the above s clear.

Here is the picture.. Many Thanks!

RayR

[JDave]

QUOTE(JoeLabview @ Jan 24 2008, 03:36 PM)

I am looking for suggestions on how this coding approach can be improved. I want to programmatically build a cluster of arrays than can be later unbundled by name.

The way the cluster is populated is by first reading a database Table and listing all the columns within that Table. The column contains elements of various types, that will be handled properly and not be part of this particular exercise.

...

However, at the bundle into array, I want to wire it in such a way that I can unbundle by name later. So the databse cluster would contain the name of the column where the data originated from. That way, a sub-vi can access the element array by unbundling by name. Simple. Plus the idea is that this can be used for any database with any column names and the end result would be the same, a cluster of arrays that can be indexed by name of the column which it originated from.

A thought that came to mind to accomplish your design with a different technique is to use Variant Attributes. You assign them by name and access them by name. So after you read in the column names from your table, you set the variant attributes using those names.

See here and here.

[LAVA 1.0 Content]

Thanks JDave!

Yes... I've thought of using Variants.. Especially since the database is presented as a 2D Variant array.. Maybe I should just deal with Variants instead of converting and searching and so on.

At one time, I was attracted to Variants and someone told me to stay away.. Somewhere on the NI forum.. But I like those examples you pointed to.

What the heck.. Variants it is.

Now since I came back to post additional info.. Here is another image of what I wanted to avoid. ..

I'm aware of assigning the name with the constant wired to the type of the Variant To Data. I wanted to make something more universal..

I'd still like to learn that technique... as an aside to the original topic..

[Mark Balla]

The Open G vis "Get cluster elements by name" and "Set cluster elements by name" come in very handy when you are trying to programatically bundle and unbundle.

You can also extract data types and get the cluster items as an array of variants by using the vis in the LabVIEW 8.5\vi.lib\Utility\VariantDataType folder

[LAVA 1.0 Content]

Thanks mballa,

This is close.. but not quite what I'm looking for.

Imagine what you posted, but no Cluster control. So no source of name.

Where I see a recurring use (for instance) is the ouput of a number of math steps that end up in an Indicator. Let's say you remove the indicator and wire that to a Cluster. Next to this would be a string array that contains a list of labels. I want to... hum... maybe what you posted would work.. with a slight modification..

I was about to say.. "I want to assign the name of each element in the cluster a name from the label array". I will go visit the Open G vi's. You gave me an idea..

THANKS!!

[studiobods]

Hello, 

 

DB for LabVIEW is a new Toolkit Compatible with LabVIEW can help you a lot to do what you want.

It uses the LV Database and Connectivity Toolkit to connect your existing database, automatically get the database structure and columns data types. Then, with this information, it automatically generates a LabVIEW Polymorphic VI for your database, and this VI will returns your database records in clusters instead of variants.

There is also many other advantages using this DB for LabVIEW since it automatically gives you access into one VI, to all queries, all tables, and populates columns names for you.

 

You can try this toolkit by downloading it on http://studiobods.com/en/produits.html

It will also be available on the LabVIEW Tools Network in few days.

 

[Phillip Brooks]

About a year and a half ago I submitted a simple script based VI to create a cluster based on a DB table to the NI Community forums.

 

https://decibel.ni.com/content/docs/DOC-19512

 

It looks like you went the extra steps of enumerating the column names and creating the CRUD polymorphics. This sounds like a great tool for someone who is not a DB expert but needs to quickly interface to an existing DB.    

 

The only question/issue I see would be if the DB changes, how does the user update the generated VIs?

[studiobods]

Hi Phillip,

You are asking a good question.

All the generated code is using type definitions to define the database structure (columns names and types, etc...)

If your database structure changes, you just need to regenerate the database driver with this tool, replace your code with the new one, and it will be automatically updated with the new structure.

I hope it's clear.

 

Regards,