topic Re: Non-empty recordset reading empty? in LabVIEW

Non-empty recordset reading empty?

Fritz_Reitz — Thu, 24 May 2012 19:46:56 GMT

have a labview 2011/database connectivity toolkit VI working on one computer but not another.

working computer returns data from table as expected (via .udl file pointing to .mdb file)

on non-working computer, attempts to read non-empty table happily return empty recordset (no error returned).

Database Fetching.vi example program runs fine on both.

any thoughts on how I managed that?

Re: Non-empty recordset reading empty?

PhillipBrooks — Fri, 25 May 2012 16:31:40 GMT

Maybe the Database Name in the UDL is using a drive letter like C: ?

If so, Use a network share name instead.

Share the folder containing the MDB file; then change the Database name to use share name like

\\PC_NAME\SHARE_NAME\my_access_db.mdb

Re: Non-empty recordset reading empty?

Fritz_Reitz — Fri, 25 May 2012 17:05:50 GMT

very interesting, hadn't thought of doing it that way. doesn't seem to quite do the trick just here though, 2nd computer has own database and .udl's "test connection" says it's ok whether .mdb specified with drive letter or share name, but reading the table comes back empty.

Re: Non-empty recordset reading empty?

Fritz_Reitz — Wed, 15 Aug 2012 19:08:19 GMT

update: ultimately switched to .accdb file format and issue went away

Re: Non-empty recordset reading empty?

jborland — Tue, 29 Oct 2019 14:04:19 GMT

I am having the same problem in our production environment. Everything works in the test environment - when I move the .mdb from production to test, it works. But when I connect to that exact same database in the production location, via the file share name, I get the empty recordset. And the strange thing is, everything worked in production until a couple of weeks ago. What could be going on here?

Re: Non-empty recordset reading empty?

jborland — Tue, 29 Oct 2019 18:03:32 GMT

OK, it turns out someone renamed the directory that the production database was in, and we didn't notice it because the names were very similar. Our error handling may need some work as we did not see the error until we stepped through the code with Highlight Execution turned on.