I have a db in access 2003 it needs to run on an access 2010 machine, all this is ok now and it works fine, but i had to remove the line option explicit, even though i had defined all variables.
My question is why is this so.
I have a db in access 2003 it needs to run on an access 2010 machine, all this is ok now and it works fine, but i had to remove the line option explicit, even though i had defined all variables.
My question is why is this so.
Why did you have to remove? What error message were you getting? Did you have to remove from every module?
This should not have been necessary.
How to attach file: http://www.accessforums.net/showthread.php?t=70301 To provide db: copy, remove confidential data, run compact & repair, zip w/Windows Compression.
Yeah, not necessary at all if you are defining all of your types. Error messages would help.
This is probably not the issue, but if you know that everything is as it should be etc, etc. and you tried everything else, sometimes decompiling the code will help. You have to do it from the command line but if code is behaving erratically, sometimes this is the only thing that will fix it for me. Make sure you back-up first!
On the command line it will look something like this "<path to MSACCESS.exe where MS office is insalled>" /decompile "<path to file where access database is>"
Replace stuff in brackets with actual paths of course. Leave in the quotes.
Extra hint: If this is going to be used by multiple people with different operating systems, decompile on the oldest operating system.
Last edited by drexasaurus; 02-13-2014 at 05:40 PM. Reason: Thought to remind about quotes right after I pressed save
I agree with most of the others, I would go as far as to say you're definitely mistaken. If the only change you had to make to enable the project to compile was by removing Option Explicit, then by definition, that means: (for sure) - that you did not have a variable properly typed. Directly or indirectly. There is no other reason.
There may be other things that appear to be reasons
And you should NOT remove option explicit. You should leave it there and figure out what the problem is, rather than disguising the problem by just removing the very item that is telling you you have a problem. Removing option explicit is like putting a patch over your eye so that you no longer see a problem...rather than fixing the problem..
Did you have to do this for one Form, or all Forms? Assuming that your statement above, in red, is correct, I can only think that if it's one Form, that Form is corrupted. If it's all Forms, I'd guess that the Database, itself, was corrupted.
Easiest first step would be to Import everything into a new, blank database.
As has been said, it really is advisable to use Option Explicit.
Linq ;0)>
The problem with making anything foolproof...is that fools are so darn ingenious!
All posts/responses based on Access 2003/2007
Did you have to do this for one Form, or all Forms? Assuming that your statement above, in red, is correct, I can only think that if it's one Form, that Form is corrupted. If it's all Forms, I'd guess that the Database, itself, was corrupted.
Easiest first step would be to Import everything into a new, blank database.
As has been said, it really is advisable to use Option Explicit.
Linq ;0)>
Respectfully would disagree with that. The next step is not assuming corruption, it's Compiling the database and reporting to those who are helping, at what point the compiler objects. Provide the line of code that offends, and the entire Sub/Function wherein it's contained.
And, let us know what the error actually was, or what made you think you had to remove option explicit. Learning how to compile and how to react to compiler errors should come first, before assuming anything is corrupted which I doubt it is..