From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Non-empty recordset reading empty?

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?

0 Kudos
Message 1 of 6
(2,415 Views)

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

 

 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Message 2 of 6
(2,397 Views)

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.

0 Kudos
Message 3 of 6
(2,393 Views)

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

0 Kudos
Message 4 of 6
(2,363 Views)

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?

0 Kudos
Message 5 of 6
(1,919 Views)

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.

0 Kudos
Message 6 of 6
(1,895 Views)