ChuckBorisNorris

Looking a bit further into it, I think the missing DLL was actually part of the Access run-time which I notice is installed separately. If I had repaired/uninstalled that then maybe I could have avoided all this hassle.

To anyone who has this particular error in the future, check to see if the Access run-time engine is installed separately (Start > Control Panel > Programs & Features) and if so, try fixing that first.

Our companies Office installation is a bit weird apparently, even the IT team think so. 

Solved. 

I downloaded the process explorer mentioned above and saw that there was one Access-specific dll missing between the good and bad applications: ACEES.dll.

I copied this over from the good machine into the correct folder (C:\Program Files (x86)\Common Files\microsoft shared\OFFICE14 on my machine, it may be different for other people) and everything appears to be running smoothly.

Thanks JKSH, yatta!

P.S. How do I mark this post as solved?

Hi JKSH,

I didn't decide our company's policy on Office installations so I don't know how or why we have Access2013. Is that relevant?

I'll take a look at the DLL list and and let you know what I find.

Thanks,

jcarmody,

I'm not pulling out that sledgehammer just yet.

A complete reinstall of Office365 hasn't helped.

Back to NI/Microsoft support I guess...

So, thankfully there were no zero-length characters in the query string.

I've just done a complete uninstall/reinstall of Office365 and the problem still persists, just to confirm that I've tried this avenue.

A bit more info: The built application, when accessing the same database from a different machine on the same network has no issues. The error is only reported on my machine.

So the syntax is correct when sent from one PC but not the other, maybe that's a clue?

Hi LogMAN,

I'm waiting on our IT guys to do a complete reinstall as we speak, I'll let you know what happens.

I hadn't thought about zero-length characters, it's worth a shot!

JKSH,

The error message is the same, the only difference is either  "in query expression '[UserID]'" ,  "in query expression 'UserID'"  or  "in query expression '*'". The rest is the usual blah blah about undefined error codes.

Is there a way to check the call as it goes into Access?

Gribo,

I have a W7 (Windows 7) installation.

Hi JKSH,

Yeah, I know it's a syntax error, that's why I'm so confused.

I have tried all of the above (and without the ; as well), all give me the same error.

Surely you can agree there's nothing wrong with the original syntax though, and like I said, the query functions fine in Access2013.

No joy I'm afraid. The link took me to an Access2010 runtime which failed to install, probably because I already have Access2013 installed.

Looking back at the problem, I doubt this would have worked anyway since I have no issue connecting to the database and closing the reference at the end. It almost looks like a syntax error in the query but the query is so trivially simple... (quick look at original post), yep, nothing extreme going on here.

It's the best lead I have so far. Thanks, I'll let you know what happens.

This clearly isn't a very common issue so all avenues are welcome.

Hi All, Long-time lurker, first-time poster here.

As the title (hopefully) implies, I have an issue connecting to a database I've created. 

The problems started this week after coming back to look at the project after ~3 months. I know I had to repair my Office 365 installation last week and I'm wondering if that could be the cause but other than that I'm at a complete loose end.

Microsoft support say it's a LabVIEW issue, NI support say it's an MSDN issue. The official NI forum, after looking at similar posts, was even less helpful. So I thought I'd come and see if the nice guys at LAVA had experienced a similar issue.

I'm aware that the error code is a generic one and has multiple causes but I am simply writing a "SELECT [column] FROM [table];" statement to an 'Execute Query' vi. The error returned from my sanity checking vi is: 

(Code -2147217900) NI_Database_API.lvlib:Conn Execute.vi->Untitled 1<ERR>ADO Error: 0x80040E14
Exception occured in Microsoft Access Database Engine:  in query expression '[UserID]'. in NI_Database_API.lvlib:Conn Execute.vi->Untitled 1

The connection string returned is (without line breaks):

Provider=Microsoft.ACE.OLEDB.12.0;
User ID=Admin;
Data Source=T:\PROJECTS\02-ACTIVE\119888 RF Power upgrade\Database\RFPU.accdb;
Mode=Share Deny None;
Jet OLEDB:System database="";
Jet OLEDB:Registry Path="";
Jet OLEDB:Database Password="";
Jet OLEDB:Engine Type=6;
Jet OLEDB:Database Locking Mode=1;
Jet OLEDB:Global Partial Bulk Ops=2;
Jet OLEDB:Global Bulk Transactions=1;
Jet OLEDB:New Database Password="";
Jet OLEDB:Create System Database=False;
Jet OLEDB:Encrypt Database=False;
Jet OLEDB:Don't Copy Locale on Compact=False;
Jet OLEDB:Compact Without Replica Repair=False;
Jet OLEDB:SFP=False;
Jet OLEDB:Support Complex Data=False;
Jet OLEDB:Bypass UserInfo Validation=False;

The BD for my sanity check looks like this:

I'm using LabVIEW 2016 32-bit on a W7 Dell Ultrabook with Access2013 as part of our Office 365 installation. BTW the query executes fine in Access2013. Is that enough info?

Regards,

Boris