I wrote earlier describing how Visual Basic codes and Macros regarding date modified fields being updated with the current weren't allowed on certain machines while it worked perfectly fine on mine. I have noticed another abnormality along the same lines.
Before I describe this newest problem, I will note that many have suggested I open up a code module, select "tools, preferences," and look for any options which are described as "missing." Well, when I tried this, the "preferences" choice was dimmed altogether. I was unable to make any changes there.
The newest abnormality I have noticed is that any function--even if it's not a macro or Visual Basic code--it doesn't like the Date() function. For example, I have a text box on a form where the user enters the date for searching purposes. The "default" value of this text box is Date(), so that if the user is referring to the current date then they are saved from having to type out that date.
I have noticed that even this is not allowed at the same computers which gave me problems with Visual Basic/macros earlier. In the aformentioned field, I see the "#Name?" label. It's obvious these computers simply don't support current date functions.
Is there any fix for this?
Larry
Please take a look at the following article:
http://www.mvps.org/access/bugs/bugs0001.htm
--
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
From Albert Kallah kallal@msn.com
Just to clear here. You must first OPEN a module. Then you should be able to select references.
Also, on the machine that works, I would strongly suggest that you open a code module, and do a "compile and save all modules". Many times people try to move a un-compiled application that has errors in it. Get rid of all errors before you try and move it to another pc (if you don't, then you are already trying to transfer a mess...don't try it!).
So #1...try the "compile and save all modules" on a pc that works. Then try moving the mdb to another pc that DOES NOT WORK.
If, at that point the mdb does not work, then open a module (any one will do if there is more than one), and again now try the references suggestion.
--
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
From Peter Russell prussell@russellscott.co.uk
The problems are definitely down to References.
The reason the References choice is dimmed is that you are in Break mode in your code. You have to STOP your code running first before you can show references.
Regards
Peter Russell
Er, Larry, that should be Tools | References, not Tools | Preferences.
What you describe is typical of a bad reference, not necessarily to the DLL where the Date function resides, but it could be caused by other difficulties. Unfortunately, it being caused by anything but a bad Reference is so rare that most of us have never seen such a case, don't know what the specific reason would be if not Reference, and, thus, would be shooting in the dark to try to come up with a diagnosis.
And, the Date function is the Date function, whether used in code or in a property as you describe. If it isn't recognized in one place, it most likely won't be recognized in the other.
I found it was easier to just put in the date (value) yourself for example Date$() will automatically enter the current date on the database you are working with when making entries...couldnt be easier... hope this helps...sometimes i think the expression builder needs to express himself a a bit more simply!
Loraine