tags:

views:

284

answers:

2

First off, I'm using Access 2000 and DAO. I have code that executes a simple INSERT INTO query that I call using db.Execute. This code works fine inside an mdb. However, if I compile into an mde then I get

error 5 - Invalid procedure call or argument

on this line and the record does not get inserted. However, if I change from db.Execute to DoCmd.RunSQL using the exact same SQL statement the record is inserted with no problems. Does anyone know why the DAO Execute method of the DAO database object would suddenly stop working once I compile into an MDE?

Note: I only get the error if I specify the dbFailOnError option of the .Execute method. If I leave that option off, I get no error but the record is still not inserted.

EDIT:
This line fails in the MDE (but works fine in the MDB):

App.db.Execute InsertSQL, dbFailOnError

From the immediate window with a breakpoint on the above line of code:

?InsertSQL
INSERT INTO Changes
(PropertyID, FieldID, [Which], [When], [Before], Reason, ReportChange)
VALUES (1, 2, "M", #2/19/2010 4:51:44 PM#, "Suite 2; 430 W KING ST; ABBOTTSTOWN, PA 17301-9771", "Per Owner", True)

(I have an entire class module dedicated to building and executing SQL statements, so it's not really practical to show exactly how I built the InsertSQL string variable. However, I really don't think that is relevant.)

This line works everywhere:

DoCmd.RunSQL InsertSQL

EDIT: App.db definition (note that there is no reference in my project to ADO, only DAO):

Public App As New clsApp

clsApp class module (relevant lines only):

Private m_objDB As Database

Public Property Get db() As Database
    Set db = m_objDB
End Property

Private Sub Class_Initialize()
    Set m_objDB = CurrentDb
End Sub

Private Sub Class_Terminate()
    Set m_objDB = Nothing
End Sub

If you are curious, I use App.db rather than CurrentDB for two main reasons: 1) slight performance gain by not having to call the CurrentDB function repeatedly (call it once then just refer to the object it returns) and 2) properties of the database object like .RecordsAffected always return relevant information. Plus, it's faster to type. And I'm a programmer, so I'm inherently lazy.

EDIT: Let me first apologize to those who have been following this thread and trying to help me. It seems I may have left out the critical details of my problem. The App.db.Execute call takes place inside a class module (clsSQL) and it references a global variable named App which is itself an instance of a different class module (clsApp). I'm guessing the problem is that I am referring to an instance of a class module from within another class module. Can anyone confirm if calling one class module from within another is something that is supported by MDBs and not MDEs?

A: 

Chances are you are using a forms control reference inside the string you are passing to the Execute statement. That is me!ControlName is inside the quotes. Change it so it's outside the quotes. That is change ".... SELECT me!ControlName As Field1, Field2, Field3 ..." to ".... SELECT " & me!ControlName & " As Field1, Field2, Field3 ..."

Thus VBA can convert the value of the control name properly. Docmd.RunSQL does this for you. Execute does not.

Tony Toews
Doesn't apply to this situation. See my edit above. Thanks for taking the time to help, though.
mwolfe02
A: 

What version of DAO do you have in your references? It might be that the older version is working fine on the mdb but fails on the mde. Try setting this to the latest version and compile it again

Kevin Ross
I would not blindly suggest using the latest version whatever it might be. DAO 3.6 should be the version in the references and is the latest version. It comeas as part of Windows 2000, XP, Vista and 7 so it would be rather unlikely to have a different version. There is no newer version unless you want to use the ACE DAO which is part of A2007 and newer. Which I wouldn't recommend for a variety of reasons although it might very well work.
Tony Toews
You should use the version of DAO that goes with the version of Access you're using. If A2000, A2002, A2003, ADO 3.6, and if A2007, the ACE DAO version. No exceptions.
David-W-Fenton
Prehaps I should have said use the correct version for the mde and not the "latest" version. I think the advice is still sound
Kevin Ross
DAO and MDE version are not really the relevant issues. It's MDE and VBA version, and each version of Access has its own version of VBA. That said, a 2000-produced MDE will run in 2002 and 2003 (and, I assume, 2007), and so forth (i.e., forward compatibility), but an A2002 MDE won't work in A2000 (not backward-compatible).
David-W-Fenton
DAO 3.6 is indeed the version in the references.
mwolfe02