"operation is not allowed when the object is closed" error

[Mark Lea]

I have dropped a Microsoft ADO Data Control onto a LabVIEW form in order to connect to a MySQL database via ODBC.The connection works fine and reading from the data base works fine using SQL but when I try to write to the database using an SQL statement such as 'UPDATE table SET column=something WHERE column=something' I get a POP-UP stating 'operation is not allowed when the object is closed'.The table is actually updated so all I need to know is how to get rid of this infuriating POP-UP. Any ideas???

[csch]

Hi,

I had exactly the same problem. See "Old Easy SQL VI with Database connectivity tollkit 1.01" in the discussion forum.

I must say that NI is aware of this problem.

The problem is in the VI "Easy SQL.vi". It executes the SQL query and call the vi "Fetch Query Results.vi" which call the vi "Get Number of Records.vi".

Since INSERT and UPDATE statements have no results, the ADO object state is set to "closed" but the vi "Get Number of Records.vi" don't test the object state before asking for the number of returned records and you receive this error.

I modified the vi "Get Number of Records.vi" and now it works fine. The problem is that this vi is a part of the core of LabVIEW database connectivity toolset and you'll loose this modification when you
reinstall this toolset or install your application on another machine.

The vi "Get Number of Records.vi" is located here:
..\LabVIEW 6.1\vi.lib\addons\_sql\Intrface\FETCHi.llb

In attachement you'll find my modified vi.

I hope it will help you.

[Mark Lea]

Thanks for the reply csch.
Unfortunately I am not using the Database connectivity Toolkit but I have just written a handler in VB that is called by the vi to use INSERT etc statements.
I have discovered that if I use recordset.Close at the end of the handler I get exactly the same problem but if I leave it out the problem dissappears. The recordsets are all closed when the program ends afterall!. Perhaps this is where NI need to look in rectifying the problem.

Mark lea