MSAccess - Date(), Str() function causing Runtime Error 13 in ACCDE

In development, MS Access 2010, queries using the Date() function and Str() function work just fine.

When I compile to an ACCDE however and run under Access Runtime 2010, execution of these queries generates a runtime error 13, type mismatch.

All references are set correctly. If they were not, the functions would not work in development.

Thank you.
Who is Participating?
Nick67Connect With a Mentor Commented:
I have to agree that you are probably having a reference issue.
All of the references MUST have the exact same path on the development machine and the production machine.

32-bit machines vs 64-bit machines (Program Files vs Program Files(x86))
Office 2003 vs Office 2007 vs Office 2010 (Office 10, Office 11, Office 14)
Different drives (c: d: ect)

If the run-time isn't installed to exactly the same path as the full-blown Office, you may have grief.  Look at the path to MsAccess.exe on both machines.  Is it an absolute match?
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database ArchitectCommented:
Do you mean like:

Dim x

x = Date()

and you get a type Mismatch ?

Also, in your dev  environment you can emulate the runtime scenario by starting your db using the Runtime switch off the Command Line ... fyi ...

akivashapiroAuthor Commented:
Actually, not in vba, but in a query:

SELECT Date() AS [Test 2];

You may have to add a table in for the query to run.

I tried it with the runtime swtich, and it still worked in my development environment.
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to and use offer code ‘EXPERTS’ to get 10% off your first purchase.

akivashapiroAuthor Commented:
In addition to Date() and Str() it seems also Ucase() does not work.

Please see attached.
DatabaseMX (Joe Anderson - Microsoft Access MVP)Connect With a Mentor Database ArchitectCommented:
These are *classic* cases/examples of a Reference issue ... almost ... guaranteed ... can't think of much else at the moment.

Are you saying that you have the runtime and the development versions installed on the same machine?

If not, then it just looks like a common references problem.  Any differences in library file locations or versions between the development machine and the runtime machine  can cause reference failures.
akivashapiroAuthor Commented:
I found the solution. The development machine was running Office 2010 and the production machines are running Office 2007. Three type library's referenced in development did not exist on the production machines for Outlook, Excel, and Word 2010.  I copied those type libraries to the production machines on the same path and it worked. <br /><br />What is strange is that instead of an error at load time or an error that indicated an "unknown function" or some such, I got a type 13 type mismatch error. <br /><br />Thanks for your input.
Busted references tend to make mundane function stop working--which is why all of us were pretty sure that you had a reference issue.  The error messages tend to be misleading.  What happens is that fairly mundane functions run, and they are known by the VBA code, but they have some dependencies on the busted references, and then things go BANG!

Glad you got it figured out!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.