Password fails after a while using Database Connectivity Module...

[Kevin_R]

I've got a bug that is driving my users and I crazy.  We use a MS-Access database to log the process steps performed by an experimental system, controlled by LabVIEW (7.11) running on multiple workstations; the Access db is on another, independent workstation.
The process log records are time-stamped when created we can rebuild the experimental sequences we've been running.

A DSN file on each process workstation points them at the database files on the db workstation. For simplicity's sake we map the directory with the files as network drive X: and the local DSN file references it that way.

This all works just fine, for a while, and then suddenly when creating/updating a process record we get a password prompt from the connection subvi, the password will be rejected, and any further attempts to connect to the db fail.

Stopping and restarting the application will restore the ability to connect (until it fails again). It is not necessary to exit LabVIEW or unload the application VI from memory, simply to stop it and restart it.

Can anyone suggest where to look for the problem?   Is the network drive mapping/the problem?

Any suggestions would be appreciated. We're about to ramp up our experimental work and this bug keeps stopping the experimental process (or worse, if the user cancels past the password prompt, the process steps are not recorded in the database).

[Will_S.]

Does this happen after the same number of records each time? The same duration of time? What kind of security settings do you have with your database?

[Kevin_R]

Hi Will -- sometimes it happens on the second-to-last of a series of about 30 updates, sometimes it happens on the first or second, or on an individual update.

I may, however, have found and fixed the problem.

The group member who wrote the original version wrote a small subvi to confirm that the stored password being submitted was valid before attempting any actual db queries/updates.

That subvi opened a connection with the password and then closed it, and returned a Boolean TRUE and the validated password if the connection was successful. The calling VI then used that validated password to open another connection and proceeded with its assorted SQL queries, then closed that connection.  This sequence was repeated every time a process record was updated (so, for instance, if we were refreshing the status of all the samples installed in the apparatus, it would happen around 30 times).

I suspect one of two things was happening: either the rapid-succession connect-disconnect-connect was just happening too fast to always get a valid db connection, or the timeout in the connection subvi was too short (he was using the default of 15s).

I rewrote the password-validating subvi so that rather than closing the connection if successful, it passes it back out to the calling VI to be used for the db queries/updates. I also set the timeout when calling the connect-to-db function at 30s rather than the default of 15s.

So far, we haven't been bothered by any more password prompts. I've got my fingers crossed that it's actually fixed now.

[Will_S.]

Your fix sounds like a much more efficient way of coding the password check as well. Please post again if the problem shows up again.