Error -2147352571 occurred at Variant To Data

[DuffmanSays]

Jason,

I assume that you are working in LabVIEW 8.20? I was able to replicate this behavior in LabVIEW 8.20, but the problem was solved by following the instructions in the linked KB. At this point, I would recommend a reinstallation of the Database connectivity toolkit. I should mention that you will still need to replace the dir.mnu file in order to use this VI. This file should replace the file at the following directory:

<LabVIEW>\vi.lib\addons\database

I apologize for the inconvenience that this has caused in your application. I am confident that the VI should work properly with a fresh installation of the toolkit and this replacement file. Please let me know if that does not work for your application. Thank you very much,

Mike

[kelljw31]

Mike,

Thanks, I did reinstall and can add the Database Variant to Data function to my block diagram now.

I am wiring an array of strings as the type and still have an error.  Error 91 occurred at Database Variant To Data in Variant2Data.vi; "LabVIEW:  The data type of the variant is not compatible with the data type wired to the type input."  If I wire a single string, the vi runs and returns a single value but I am looking for multiple values to come back.  Any suggestions on what I can do to get to where I want to be?

I have attached the vi I am working with.

Jason

[DuffmanSays]

Jason,

I am very glad to hear that the reinstall worked for you… the world still makes sense to me.

As for the issue with error 91, the Fetch Element Data is not returning an array of strings as you are expecting. This occurs because the Fetch Element Data VI will return only one record at a time. This is why you receive the first record in your data set when wiring a string to the Type input. You could use the DB Tools Move to Next Record VI in a loop to then access the next record in the recordset.

While the above solution would work for your application, I would actually suggest using the DB Tools Fetch Record Set Data VI. This will return a 2D array containing the results of the query you execute. It appears that you are only interested in the "Results" field; I would suggest modifying your query such that only this field is returned. Please take a look at the attached example code and let me know if this works for you. Thanks,

Mike
National Instruments
Applications Engineer

[Crystal]

Actually, the Fetch Element Data does exactly that... it returns a single element from a record (row).  Using the Fetch Recordset Data should return all the information you request and then you can either convert everything to strings as shown in the Query VI or you can index out each element and convert it to the appropriate type as shown in many of the examples (such as the Sixtypes Select).

[kelljw31]

I believe I have heeded everyones advice to this point.  I am now back to the original error message.  I have attached the recently modified file.

[Crystal]

It appears that you have a type mismatch between what is in the database and what you want to convert it to in LV.  Is there any way you can attached the database file or at least a screen capture showing the datatypes for each field?  Also, it would help to see the diagram of the VI that writes the data to the database.  Somewhere there is a type mismatch.  What happens if you convert the variants to string?  What data or errors are returned then?

[kelljw31]

Crystal,

I have attached a print screen of the SQL table design and the vi I use to write to this table.  If I convert to a string and not an array, it works but it only pulls back one piece of data, the first piece.

[Crystal]

Sorry I've not replied sooner, I've been traveling and was really busy.  I noticed that when I looked at your table definition and then looked at your INSERT statement, there were a number of inconsistencies.  For example, you specify in the INSERT eleven fields to insert into but only give ten parameters.  Also, those ten parameters do not agree with your datatypes in the table definition.  Strings have the quotes around them, but numbers don't and I notice that for a couple of the string fields, you don't put quotes and for some of the numbered fields, you do put quotes when they aren't needed.  This confusion with the field types could lead to the problems you are seeing trying to convert the data back. 

Did you first try reading the whole table and converting to strings?  This might show in better detail which fields are which and how they are converted correctly.  You could also attach an example table with the fields you are reading and the VI that reads it.  But I do think at some point you are getting string and numeric fields mixed up at some point.