We recently completed updating our Access database to .accdb format and using the ACE.OLEDB driver. Last week (Apr. 29th), one of our tracking functions began to fail with the message: Microsoft Access Database Engine error '80040e14' Syntax error in INSERT INTO statement After testing, including checking the Microsoft documentation, the on-line SQL syntax verification that shows the syntax to be 100% correct, and other sources, we are still getting the error. The current syntax is: INSERT INTO AdTrack (LogIn, Admin, Action) VALUES ('" & LogVal & "', '" & WhoAdm & "', '" & DidWhat & "'); Everything is simple plain text except LogVal, which is a date & time compilation that is converted to text. Our own syntax checker returns the result which appears to be valid: INSERT INTO AdTrack (LogIn, Admin, Action) VALUES ('2019/5/1/11', 'John Smith', 'Upload of email attachment failed at 11:30:00 AM: '); This same syntax worked for over 20 years using the .mdb format and MS-Access driver. Any help and insights are appreciated.
It looks correct to me. The only thing I can think of to help you troubleshoot the problem is output the SQL string with a few iterations to verify that the syntax is correct.
Yes, I've been trying different iterations from the day the insert process failed. I have yet to find one source that suggests that the syntax is incorrect, except for the error message on the server, and even that worked for years until a few days ago.
Well, after a lot of frustration, including tests that used straight text in place of the parameterized content, I went back to the "old" microsoft driver. The tracking function now works with no syntax errors. I wish I could use the newer ACE.OLEDB driver, but it seems to be rather quirky with Access database files.
Sorry to hear that, and thanks for posting the solution or work around. I'm sure it will help others out in the future.
Did you try this with the more standard Date/Time Delimiters: #019/5/1/11# instead of the implicit conversion of the string delimiter used in the sample you posted. It has been my experience that newer versions of Access, i.e. ACE, tend to be less tolerant of ambiguity.