Access 2003 Problem with DAO360.DLL error 3072 unknown function (findfirst)
I have written an extensive program in Access VB (originally in Access windows then converted to Access 97 then converted to Access 2000 then Access 2003)
The program resides on a network at a college. Recently, they changed some of the machines with different versions of Office 2003. I then moved all of them to Office 2003 SP2 (to be consistant).
The problems began with one of the users receiving the 3072 error, when debug is clicked the module was trying to run findfirst. The other PCs run fine.
If I open Access VBA on the machine that had the errors, go into tools/references and uncheck DAO 3.60. Get our of the database. Go back into the database and recheck the DAO 3.60, the PC works, but then all of the other PCs on the network get the 3072 error on the same line (findfirst).
I have registered the DAO360.dll on all the pcs (regsvr32 "c:\program files\common files\microsoft shared\dao\dao360.dll") and tried unchecking and checking the DAO 3.60 in references but to no avail.
They are all part of the same workgroup in Access (tools/security/workgroup admin).
I am not sure if there is some file incompatibility in office, the dll libraries, I have copied the same dao360.dll on all the PCs.
Peace,
lpii
The program resides on a network at a college. Recently, they changed some of the machines with different versions of Office 2003. I then moved all of them to Office 2003 SP2 (to be consistant).
The problems began with one of the users receiving the 3072 error, when debug is clicked the module was trying to run findfirst. The other PCs run fine.
If I open Access VBA on the machine that had the errors, go into tools/references and uncheck DAO 3.60. Get our of the database. Go back into the database and recheck the DAO 3.60, the PC works, but then all of the other PCs on the network get the 3072 error on the same line (findfirst).
I have registered the DAO360.dll on all the pcs (regsvr32 "c:\program files\common files\microsoft shared\dao\dao360.dll") and tried unchecking and checking the DAO 3.60 in references but to no avail.
They are all part of the same workgroup in Access (tools/security/workgroup admin).
I am not sure if there is some file incompatibility in office, the dll libraries, I have copied the same dao360.dll on all the PCs.
Peace,
lpii
if jpaul's suggestion doesnt resolve this, then
is this a split app? ie front end in one db (on user pc), back end (data) in another?
if so then
1) give that problem pc the version that works.
or 2) have a form with a textbox where the user can enter (or select) the path to the dll, then programatically remove and add the dao reference.
is this a split app? ie front end in one db (on user pc), back end (data) in another?
if so then
1) give that problem pc the version that works.
or 2) have a form with a textbox where the user can enter (or select) the path to the dll, then programatically remove and add the dao reference.
ASKER
It is not a split app. It is one .mdb that sits on one of the schools servers.
I will try the unreg and reg tomorrow.
lpii
I will try the unreg and reg tomorrow.
lpii
ASKER
I just tried to unreg & reg on the machines. No go.
I still have to click on the tools/reference & select DAO 3.6. If I do it on the one pc that has the issue, the other three pcs do not work. If I do it on one of the three machines then the 4th machine will not work.
I am going to try and have the college do a reinstall and see what happens, but would still like any other suggestions that you may have.
lpii
I still have to click on the tools/reference & select DAO 3.6. If I do it on the one pc that has the issue, the other three pcs do not work. If I do it on one of the three machines then the 4th machine will not work.
I am going to try and have the college do a reinstall and see what happens, but would still like any other suggestions that you may have.
lpii
check the location of the DAO dll on each machine. it sounds like they were installed in different locations on those pcs's.
if thats the case you need to either uninstall and reinstall access on that pc with the issue (the best way) and ensure all future pcs using your app has access installed in the same directory (it may be under the windows directory so if they all have different operating systems create the same relevant subfolder and copy the dao dll into that subfolder),
or you have write code to dyamically reference the DAO dll for that user (store the paths in a table, paths specific for each user path that is different).
if thats the case you need to either uninstall and reinstall access on that pc with the issue (the best way) and ensure all future pcs using your app has access installed in the same directory (it may be under the windows directory so if they all have different operating systems create the same relevant subfolder and copy the dao dll into that subfolder),
or you have write code to dyamically reference the DAO dll for that user (store the paths in a table, paths specific for each user path that is different).
ASKER
I did uninstall & Reinstall. I actually did that last week. Tthe DAO was in the same loaction on each PC even the one not working, and they all had the same copy of DAO (I used the DAO from one of the machines that were working. The Issue was solved though in a strange round about way with a reinstall on Thursday.
The campus uses an image file from the server to do the install, but the actual Office files do not reside on the PC (though the .dll's do get installed on the local PC in the microsoft shared directory as well as the windows & system directory).
We actually had to do an install from the CDs and make it a local install so that the Office files were physically located on the C: drive. On the three PC's that worked, Office was installed on the local drive.
Even though the .dll's were on the bad PC, there was something in the office directory that needed to be physically located on the PC, what that was, I have no clue.
So the VB code works fine now. Case closed.
lpii
The campus uses an image file from the server to do the install, but the actual Office files do not reside on the PC (though the .dll's do get installed on the local PC in the microsoft shared directory as well as the windows & system directory).
We actually had to do an install from the CDs and make it a local install so that the Office files were physically located on the C: drive. On the three PC's that worked, Office was installed on the local drive.
Even though the .dll's were on the bad PC, there was something in the office directory that needed to be physically located on the PC, what that was, I have no clue.
So the VB code works fine now. Case closed.
lpii
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
regsvr32 /u "c:\program files\common files\microsoft shared\dao\dao360.dll"
regsvr32 "c:\program files\common files\microsoft shared\dao\dao360.dll")