How do I specify type for Database Variant to Data?

[ltaylor-chemeng-ucla]

Apparently database variant to data is not the same as Variant to Data. How do I specify the type of data to convert it too? The Help page for DVtoD is not helpful about specifying 'type', and does not list what types are valid.
Your knowledge base does, however, give an answer for Communications Variant to Data: create a dummy (value? variable?) of the appropriate type and connect it to the 'type' terminal. I tried that, creating an array in the front panel window (is that right??), but I still get an error about 'Array "Dummy Array": control has undefined type. How do I set its type??

[mikeporter]

Could you post a bit of code demonstrating the issue?

Mike...

[ltaylor-chemeng-ucla]

I would love to, but I don't know how to include code
from a ##**&&@ iconic language.

[mikeporter]

Uhh, yes....

Ok, first create a vi that shows the effect. Next click on the button to reply to this post. Now, notice the button below the data entry box labeled "ATTACH FILES". Click on this button you will be taken on to a page that allows you to upload as many as three files. Use this page to upload the vi you created.

Mike...

[ltaylor-chemeng-ucla]

I have security concerns for anybody posting binaries. Any guarentees that posters will only posting valid vis, and not malicious .exe trojans?

My problem is related to a second question I asked a few minutes later. Question: how do I specify a type for an array? Answer: Drag something of that type into the display for the array on the front panel. I still
don't know how to set the dimensions/size of an array.

New problem: in the attached vi that evolved from the first and second questions, I have wiring representing database data from one box, DB Tools Select Data, and the next box, Database Variant to Data. As I wrote in the other question (I don't know how to refer to another question in this forum: they are unn
umbered so far as I can see...), now I have a message that the wire is broken because 2d array of variant doesn't match 2d array of variant.

I am a software kind of guy, and I find the iconic interface of LabView frustrating. Forgive my punctuation erruption. So far as I am concerned, code is source text, binaries are trouble, and those itty-bitty icons and connectors are straining my eyesight.

[mikeporter]

To take your questions in order:

1. I'm not saying that no one ever has posted malicious code here but I've never seen it and I don't see it being a problem.

2. To specify the number of dimensions for an array you right click on the index display and select either "Add Dimension" or "Delete Dimension" from the resulting menu.

3. The variant input to the conversion function is a single scalar variant value--not an array of variants. If you have an array of variant value that you want to convert into an array of strings (which is what it looks like you are trying to do) you have to convert them one element at a time. See attached example.

3a. The whole process of dealing with variants requires some careful th
ought. For example, if you take an array and pass it through the LV function that turns a LV datatype into a variant you don't get an array of variants. You get a single variant the value of which is an array.

4. Yes, things can get frustrating until you learn to think in LV. In some ways it's like any other language. There are certain ways of thinking about problems that make working in a given language easier. For example, I found working in SQL very confusing at first--how do you get anything done in a language that doesn't even have a proper conditional statement!?!? Then I stopped trying to make SQL into C or Pascal or LabVIEW. It has it's own way of defining problems and when I learned that thought process everything made perfect sense.

Hope this helps. Hang in there, things get easier, and we are all here to help each other--which is perhaps why trojans aren't a problem...

Mike...

PS: For what it's worth in terms of text-based languages I have always felt that concep
tually LV was most like Forth. But that's just me.

[ltaylor-chemeng-ucla]

Thank you for your help. However, I cannot use the attached vi in binary because you saved it from LabView 7.0 and I have 6.1. Any way to save it as an earlier version? This is most frustrating.

If you can't save it as an earlier version, perhaps you can describe it in words, or maybe post a snapshot.

These things would be a lot easier if the LabView language had a readable text counterpart. It would be next to have a command "view as text", or maybe "save as serializable (ascii)," especially for import and export purposes.

[mikeporter]

All the code does is takes an array of variants in and passes it through the left side of a For loop (so it autoindexes). Inside the loop the resulting scalar variant is connected to the variant to LV data function that has a string tied to the datatype input. The output of the conversion function is passed out through the right side of the For loop (again autoindexing).

In terms of your other comment, the conversion routine you mention wonuldn't really work because text languages are 1D lists of commands--LV is not.

Mike...

[ltaylor-chemeng-ucla]

My first attempt to reply created an error on the NI server. Maybe it was too long.

For this issue, it would help me if you detailed the contents of this for loop. I have never done it before. Also, maybe you can take a screen shot of the window containing your 7.0 function.

[ltaylor-chemeng-ucla]

Here is another part of the posting that crashed.

Programs in LabView, like all computer languages, is formally equivalent with programs written in other languages, with only a few caveats.

Like Forth, which you mentioned previously, LabView is a functional language. The wire metaphor is apt when describing data flowing in one direction, undergoing a few simple transformations or combinations. This is good for connecting the data from a physical setup, like the lab instruments.

The LabView wires are like variables in another language. Take a LabView program, assign arbitrary names to wires to make variables, and put the variables as in or out parameters of the functional equivalent
s of the LabView functions in a new language. Viola -- a serialized LabView program.

Forth could probably do it with a complicated set of stack positions instead of named variables.