Printable View
I have a user trying to open an access database and gets a run-time error 3075 in query expression Date() - [REQ_REQUES]. I've checked all references and added any that were missing, checked the regional settings, reloaded office, replaced dlls. Still cannot open database. It's not the file, because other people can open it correctly. It just seems to be this particular computer. Any help would be appreciated.
We've experienced similar difficulties with the Date() function in Access 2000, especially when it is included as the Default value in a field. It worked fine in Access 97, but stopped working after migrating to Access 2000. Including a reference to Microsoft DAO 2.5/3.5 Compatibility Library fixed most of those problems.
Have you trapped the error to figure out where it is bombing, i.e. when a form opens, or when a query tries to run? Is it an MDB or MDE database? Does the user have full blown Access 2000, or only the RunTime version? Does the database link to the tables it uses, or are they included in the database itself? Did this user have Access 97, or 2.0 installed previously?
It errors out as soon as the first table tries to open. I'm pretty sure the tables are included, not linked, in the database. We're on the network, so everyone has the same version of Office. He has all rights to the database, he can access it fine when logging onto another computer. I've even compared all the references with another computer and reloaded Office -- all to no avail. No, he didn't have a previous version of Office on his pc. No one else appears to have this problem. I think I added the DAO 2.5 library in the references and that didn't work either. We have 3.6 Object Library currently.
Any other suggestions???? I'm just at a loss with this one.
It sounds like you've covered all the bases on this. I hate it when inconsistent, unique errors occur. The only other thing I can remotely associate with this is when we converted from Access 97 to 2K, we discovered our network folks had tightened local security on user machines so they did not have the rights to create hyperlinks. When we tried to distribute a new MDE to a machine, we had to open it the first time while logged in as an Admin, or else they could not open it. Not very helpful to your situation but maybe it will spark another thought. :cool:Quote:
Originally Posted by tls68
Okay, a couple of random thoguhts. Have you tried repiring/compacting the database? Or, have tried decompiling and recompiling it? I don't know how to decompile from within access, except to call up MSACCESS.EXE from a batch file with a /decompile switch.
C:
CD \PROGRAM FILES\MICROSOFT OFFICE\OFFICE
MSACCESS.EXE /decompile
Recompiling has helped cure any number of wierdnesses, as rogue/junk code can remain hidden from previous compilations. :eek2:
I've tried so many things on this I can't remember what all they were anymore. I'll have to give the Admin login another try..it can't hurt. I didn't repair or decompile the database, because it's on the network and no one else is having any problems with it. It's just this one pc.
You've said that twice;) .. So maybe 'give up' & flatten it ? If all your other machines can access the database ok & you've updated/patched office, to me that leaves 'windozeyness' & not a lot else ?Quote:
Originally Posted by tls68
Amen. We are a fairly small shop, considering the amount of users we support, so we tend to destroy and rebuild, rather spend much time trouble shooting specific machines. However, I wish I did have the time to chase down some of those gremlins...:pQuote:
Originally Posted by confus-ed
Thanks all. that's what we are doing -- leaving it alone until something else breaks. The user isn't too concerned, he can get what he needs from another machine. And I don't want to rebuild (neither does he) until we absolutely have to!!