differences in database toolkit version 1.0.2

[warren_scott]

I'm  trying to get some database communication code working in LabVIEW 8.6 with database connectivity toolkit version 1.0.2

This code was previously working in LV8.2.1 with DB toolkit 1.0.1 (skipped LV8.5)

The code would open a database connection, execute a command to delete a table (which has no return value), the database recordset gets closed because there is no return value (behind the scenes in the DB toolkit), and then attempt to read a return value from the database, get an empty array of variants (DB 1.0.1 toolkit recognized a closed recordset reference), get no error and be happy

Now with LV8.6 / DB1.0.2 I get errors with this code, because the database record reference gets closed  and the code no longer appears to check for the closed recordset reference, so I get an error code -2146824584 message NI_Database_API.lvlib:Rec Fetch Recordset Data (R).vi ... Exception occured in ADODB.Recordset: Operation is not allowed when the object is closed.Help Path is C:\WINDOWS\HELP\ADO270.CHM and context 1240653 in NI_Database_API.lvlib:Rec Fetch Recordset Data (R).vi

Attached are screen shots of the fetch recordset data VI for both toolkits version 1.0.1 and 1.0.2

They're VERY different.  the one from version 1.0.1 handles closed references from commands that return no information, but the one from 1.0.2 doesn't appear to.

This looks like the problem http://forums.ni.com/ni/board/message?board.id=170&message.id=24209&requireLogin=False

 (Old Easy SQL VI with Database connectivity tollkit 1.0.1)

Do I have my system set up wrong, or has NI changed their direction with db toolkit 1.0.2 that requires me to go through and change the way I use this toolkit?

Thanks,

Warren

[Ipshita_C]

Hi,

Can you please post your VI so that your situation can be reproduced? It will give us a better idea of what is happening in the code.

Ipshita C.

[warren_scott]

I've attached an example VI of what we are doing.  I don't think you'll be able to run it to reproduce the problem since you can't connect to our database, but hopefully there's enough information in the comments.

Warren

[Ipshita_C]

Hi Warren,

This is indeed a bug that will be fixed in the next release. A Corrective Action Request has already been filed for it in the past and the number for that is 129511. The workaround is as you have already guessed--use the DB Tools Get Properties to check that the state is not closed and that EOF and BOF are not both true, like in our example programs. Hope this helps and thank you very much for bringing this to our attention.

Ipshita C.

[warren_scott]

Thanks for following through.

Adding those checks is working

Warren

[aliasThree]

I am having this issue as well.  I can imagine precisely how to go about modifying the VI, but I wanted to save the existing VI under a different name for safe-keeping.  Why is there no "Save as" option?  And why is the icon different after double-clicking?  Is there somewhere I can download a "fixed" version of the 1.0.2 VI (or an updated .llb)?

[David_L]

Hello,

Answer to your three questions:

The reason you can't Save As is because it is part of a purchased tookit so it's protected from copying.  If you wanted to protect your changes, you can copy it all and paste it into a new VI, but I don't think that you should have to worry with such a small change.

The reason that the icon is different when you open it is because the VI is a polymorphic VI.  If you right click on the VI and select Open Polymorphic VI, you will be able to edit the different instances of the VI.

Finally the only way to get a fixed version of the VI is to get the newer version of the toolkit.  However, the fix shouldn't be too complicated if you make the small change that was recommended by Ipshita

Let us know if you need more help.

[aliasThree]

Thank-you, David.  The changes I made to the one polymorphic version happen to be good for the other as well, since the one is actually a subVI of the other.  I appreciate your explanations.

I couldn't see a difference between "open" and "not closed", so I just keyed on whether the reference was open, without following a determination of "open" with the determination of "not closed" ((EOF AND BOF)--NOT), and it solved the problem, at least as far as I could tell.  What odd situation have I left myself open for by making this simplification?

[David_L]

Seems like it should work.  I'd say give it a try and see what happens 😄