H
hjing
fdojhodjfdodr dssfgh
DanC said:
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
D
DanC
Access Novice On Board!
I have a database created in Access97 that I have upgraded
to 2000. I attempt to run a macro that imports a text
file, where upon doing so I get the following
message: "The expression you entered has a function name
that MS Access can't find." When I look at the function,
it is, "DataImport ()" and when I attempt to build it
(rebuild it?-- delete it and recreate it), I don't
see "dataimport" as an option. Please advise.
I have a database created in Access97 that I have upgraded
to 2000. I attempt to run a macro that imports a text
file, where upon doing so I get the following
message: "The expression you entered has a function name
that MS Access can't find." When I look at the function,
it is, "DataImport ()" and when I attempt to build it
(rebuild it?-- delete it and recreate it), I don't
see "dataimport" as an option. Please advise.
W
Wayne Morgan
I don't see it either. Open the file on the old system then open the code window
(Alt+F11). Next, go to Tools|References and compare these to the ones on the new system.
Are any on the new system listed as Missing? I'm guessing that DataImport is a function
that was Referenced from somewhere else or is a user defined function. If it is the
latter, you will likely find the function in a module and the problem is probably that the
function uses DAO. Access 2000 and above use ADO instead of DAO by default.
To fix the DAO problem, in the Access 2000 version, open the code window and go to
Tools|References. Look at the checked references for Microsoft DAO 3.6 Object Library. If
v3.5 is checked, uncheck it and scroll down to check the v3.6 one. Ok to close the dialog
then go to the code editor. Do a search/replace (Ctrl+H) and change your Dim statements
for DAO objects.
Example:
Search for: As Recordset
Replace with: As DAO.Recordset
Search what: Entire Project
Do this for other DAO objects as well (Database, Querydef, Tabledef, etc).
(Alt+F11). Next, go to Tools|References and compare these to the ones on the new system.
Are any on the new system listed as Missing? I'm guessing that DataImport is a function
that was Referenced from somewhere else or is a user defined function. If it is the
latter, you will likely find the function in a module and the problem is probably that the
function uses DAO. Access 2000 and above use ADO instead of DAO by default.
To fix the DAO problem, in the Access 2000 version, open the code window and go to
Tools|References. Look at the checked references for Microsoft DAO 3.6 Object Library. If
v3.5 is checked, uncheck it and scroll down to check the v3.6 one. Ok to close the dialog
then go to the code editor. Do a search/replace (Ctrl+H) and change your Dim statements
for DAO objects.
Example:
Search for: As Recordset
Replace with: As DAO.Recordset
Search what: Entire Project
Do this for other DAO objects as well (Database, Querydef, Tabledef, etc).
D
DanC
Thanks for your help. As you said, the function is in a
module-- and it was using DAO v3.6 (not v3.5). Since that
did not have to be changed, I went ahead with the rest of
your instructions and changed the Dim statements so they
accurately reflected DAO objects. Unfortunately, I am
still getting the same error...
Thanks again for your help, and I welcome any other
suggestions.
module-- and it was using DAO v3.6 (not v3.5). Since that
did not have to be changed, I went ahead with the rest of
your instructions and changed the Dim statements so they
accurately reflected DAO objects. Unfortunately, I am
still getting the same error...
Thanks again for your help, and I welcome any other
suggestions.
the problem is probably that the-----Original Message-----
I don't see it either. Open the file on the old system then open the code window
(Alt+F11). Next, go to Tools|References and compare these to the ones on the new system.
Are any on the new system listed as Missing? I'm guessing that DataImport is a function
that was Referenced from somewhere else or is a user defined function. If it is the
latter, you will likely find the function in a module and
Microsoft DAO 3.6 Object Library. Iffunction uses DAO. Access 2000 and above use ADO instead of DAO by default.
To fix the DAO problem, in the Access 2000 version, open the code window and go to
Tools|References. Look at the checked references for
v3.6 one. Ok to close the dialogv3.5 is checked, uncheck it and scroll down to check the
D
DanC
One more thing I forgot to mention...when I made the
changes to the Dim statements, they failed to compile, so
I changed them back.
Again- big-novice-here, so maybe I did something wrong.
changes to the Dim statements, they failed to compile, so
I changed them back.
Again- big-novice-here, so maybe I did something wrong.
W
Wayne Morgan
They should not have failed to compile after you made the changes. Where the problem comes
in is that Access uses the References in the order that the checked ones are listed in the
References window. There are up and down buttons to the right of the references to change
the order that they are listed in. Since, by default, ADO is listed before DAO and both
have objects that have the same name (i.e. both have a Recordset object), Access uses the
first Recordset object it comes to, which would be the ADO one. Specifying DAO bypasses
this problem by not letting Access pick which one to use.
After the change, the Dim statements should look similar to this:
Dim db As DAO.Database, rst As DAO.Recordset
Can you copy and paste the code from the function into a message?
in is that Access uses the References in the order that the checked ones are listed in the
References window. There are up and down buttons to the right of the references to change
the order that they are listed in. Since, by default, ADO is listed before DAO and both
have objects that have the same name (i.e. both have a Recordset object), Access uses the
first Recordset object it comes to, which would be the ADO one. Specifying DAO bypasses
this problem by not letting Access pick which one to use.
After the change, the Dim statements should look similar to this:
Dim db As DAO.Database, rst As DAO.Recordset
Can you copy and paste the code from the function into a message?
W
Wayne Morgan
Dim RecordsAdded As DAO.Integer
Dan, you only need to add DAO to the DAO objects, not to every Dim statement. The 3 you
have here are NOT DAO objects and should NOT have the DAO on them, that would cause the
compile problem.
Next, try adding the word Public in front of the function.
Public Function DataImport()
Dim Garbage As DAO.String
Dim Space As DAO.String
Dan, you only need to add DAO to the DAO objects, not to every Dim statement. The 3 you
have here are NOT DAO objects and should NOT have the DAO on them, that would cause the
compile problem.
Next, try adding the word Public in front of the function.
Public Function DataImport()
W
wenwen
hi
DanC said:Thanks for your help. As you said, the function is in a
module-- and it was using DAO v3.6 (not v3.5). Since that
did not have to be changed, I went ahead with the rest of
your instructions and changed the Dim statements so they
accurately reflected DAO objects. Unfortunately, I am
still getting the same error...
Thanks again for your help, and I welcome any other
suggestions.
the problem is probably that the
Microsoft DAO 3.6 Object Library. If
v3.6 one. Ok to close the dialog
W
Wayne Morgan
Ok, change ALL of the "DAO.Integer" statements to just "Integer".
The above 2 should be
Dim dbVar As DAO.Database
Dim rsVar As DAO.Recordset
Dim dbVar As Database
Dim rsVar As Recordset
The above 2 should be
Dim dbVar As DAO.Database
Dim rsVar As DAO.Recordset
T
Tanjusha
DanC said:Hi Wayne, I apologize for the delayed reply.
I've tried adding the word "Public" in front of the
function, and after I was unable to positively determine
which objects were actually DAO objects, I removed
the "DAO." prefix, one by one, attempting- unsuccessfully
to compile each time. I've copied the rest of the DIM
statements for your review:
Dim RecordsAdded As Integer
Dim Garbage As String
Dim Space As String
Dim LastName As String
Dim EpisodeID As Long
Dim CtrctID As String
Dim Ins As String
Dim Pkg As String
Dim TotChgs As Currency
Dim NetDue As Currency
Dim Payment As Currency
Dim Error As Currency
Dim MedRecNo As Long
Dim SpaceLen As Integer
Dim LastNameLen As Integer
Dim EpisodeIDLen As Integer
Dim CtrctIDLen As DAO.Integer
Dim InsLen As DAO.Integer
Dim PkgLen As DAO.Integer
Dim TotChgsLen As DAO.Integer
Dim NetDueLen As DAO.Integer
Dim PaymentLen As DAO.Integer
Dim ErrorLen As DAO.Integer
Dim GarbageLen As DAO.Integer
Dim MedRecNoLen As DAO.Integer
Dim dbVar As Database
Dim rsVar As Recordset
Open to other ideas.
DC
W
Wayne Morgan
You removed DAO from most of the Interger declarations, but not all of them.
Interger is not a DAO object. You do have 2 DAO objects though and they
aren't declared as such. The Database and Recordset declarations are DAO
objects.
Dim dbVar As DAO.Database
Dim rsVar As DAO.Recordset
Interger is not a DAO object. You do have 2 DAO objects though and they
aren't declared as such. The Database and Recordset declarations are DAO
objects.
Dim dbVar As DAO.Database
Dim rsVar As DAO.Recordset