Date function turning to date

[Christine]

I am having the strangest problem. I use the Date function in several
of my forms and modules in an Access 2000 mdb. Lately, wherever in my
code (in this one mdb) I use the Date function, it changes to date
(lower case vs proper case). I can fix this very temporarily by
reconstructing the database (importing all objects to a new mdb) or
using the decomplie option to open it. But in either case, once I
compile it reverts back to lower case. It does not seem to impact the
functionality of the function - in other words, it still works either
way. I have played with the references and they all seem fine. But I
do not seem to be able to get it to be using Date. I have other
databases that have many of the same modules and some of the same
forms etc and none of these other DB's are having the same problem
with Date vs date. They are all on the same computer.

The reason I care about this so much, since it does 'work' is that I
have developed a Version Control kind of system for myself to help
track changes as I develop, and to make it easy to know which objects
have changed and need to be propagated to other databases. Esentially
I create a Checksum for each object and save it in an Updates table.
At least once a day, I run my Version Control and it checks to see if
any objects have a new checksum and if so, updates the Update table
and prompts me for a comment to be saved alng with the latest Checksum
for the object. My checksum formula is case sensitive so I get a
different checksum for Date than for date and thus it makes it
impossible to compare objects across DB's since identical (except for
Date) objects get a different checksum.

Has anyone seen anything like this before? any suggestions? I guess I
could change my checksum algorithm, but it has been working ok for a
few weeks and I don't know why it has started doing this now. Any
insights? Ultimately, this is all an effort to get around the fact
that Access 2000 doesn't give me a nice way to know when objects were
last modified. So I have put a lot of time and energy into trying to
compensate with my own version control solution. I'm also interested
in knowing if there are any other solutions to this out there.

TIA,
Christine

[Terry Kreft]

Most likely, somewhere in your database or one of your references is
something called date (as opposed to Date).

To be honest there is no need to worry about this as long as it is picking
up the Date function where appropriate.

If your really concerned about it just use VBA.Date and it should capitalise
correctly.

You should be able to find the offending item from the Object Browser.
--
Terry Kreft
MVP Microsoft Access
"Christine" <ct******@stny. rr.com> wrote in message
news:24******** *************** *@posting.googl e.com...

I am having the strangest problem. I use the Date function in several
of my forms and modules in an Access 2000 mdb. Lately, wherever in my
code (in this one mdb) I use the Date function, it changes to date
(lower case vs proper case). I can fix this very temporarily by
reconstructing the database (importing all objects to a new mdb) or
using the decomplie option to open it. But in either case, once I
compile it reverts back to lower case. It does not seem to impact the
functionality of the function - in other words, it still works either
way. I have played with the references and they all seem fine. But I
do not seem to be able to get it to be using Date. I have other
databases that have many of the same modules and some of the same
forms etc and none of these other DB's are having the same problem
with Date vs date. They are all on the same computer.

The reason I care about this so much, since it does 'work' is that I
have developed a Version Control kind of system for myself to help
track changes as I develop, and to make it easy to know which objects
have changed and need to be propagated to other databases. Esentially
I create a Checksum for each object and save it in an Updates table.
At least once a day, I run my Version Control and it checks to see if
any objects have a new checksum and if so, updates the Update table
and prompts me for a comment to be saved alng with the latest Checksum
for the object. My checksum formula is case sensitive so I get a
different checksum for Date than for date and thus it makes it
impossible to compare objects across DB's since identical (except for
Date) objects get a different checksum.

Has anyone seen anything like this before? any suggestions? I guess I
could change my checksum algorithm, but it has been working ok for a
few weeks and I don't know why it has started doing this now. Any
insights? Ultimately, this is all an effort to get around the fact
that Access 2000 doesn't give me a nice way to know when objects were
last modified. So I have put a lot of time and energy into trying to
compensate with my own version control solution. I'm also interested
in knowing if there are any other solutions to this out there.

TIA,
Christine

[Christine]

Terry, Thanks for your speedy response.

I tried your idea of using VBA.Date, but this still results in VBA.date
in the DB that has this problem. No matter how many times I type it in,
it immediately reverts to VBA.date - but only in that particular DB -
not any of my others. I've used the Object Explore to try to find the
source of this reference but cannot find it.

As I mentioned in my email, the reason I do care is that this behavious
is not consistent across my different DB's and I am trying to use a
checksum approach to keeping identical objects in the different DB's
synchronized by using the checksum to compare them. This variation of
date vs Date is messing up the checksums.

TIA,
Christine

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Steve Jorgensen]

One thing to watch out for is that even !<field-name> or !<control-name>
references will affect capitalization in Access VB, and it insists on having
the same word use the same capitalization -everywhere- it appears in code, so
the same code simply cannot contain Date() and rst!date. Either both are
capitalized, or both are not. You can get around this my using
rst.Fields("dat e").

That still may not be the whole story, though. I find that sometimes Access
insists on remembering a reference that's no longer around. Importing into a
new database brings this dead reference along with it, so that's no help. The
only fix I've found is to make a copy of the database with all modules removed
(set HasModule to No on all forms and reports), decompile that database, then
copy each module's text from the original database out into Notepad, fix the
capitalization, then copy and paste that into the new database. I'm pretty
sure that worked for me before.

On 13 May 2004 15:56:44 GMT, Christine <ct***@aol.co m> wrote:

Terry, Thanks for your speedy response.

I tried your idea of using VBA.Date, but this still results in VBA.date
in the DB that has this problem. No matter how many times I type it in,
it immediately reverts to VBA.date - but only in that particular DB -
not any of my others. I've used the Object Explore to try to find the
source of this reference but cannot find it.

As I mentioned in my email, the reason I do care is that this behavious
is not consistent across my different DB's and I am trying to use a
checksum approach to keeping identical objects in the different DB's
synchronized by using the checksum to compare them. This variation of
date vs Date is messing up the checksums.

TIA,
Christine

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Christine]

Steve,
Thank you so much for your insight. It turned out that one of the
controls on one of my forms was named 'date'. Once I changed that and
then reconstructed the DB again (import all objects), I was able to do a
Compile and keep the Date.

Phew... what an ordeal. I don't think I would ever have tracked that
down without your response. Also thank God for Speed Ferret, to find the
control. I have 151 forms in my mdb and most of them have modules. The
thought of dealing with each one module-free then adding the module, was
really a horrible thought.

So, I really hope this is it and the problem is gone for good. My
confidence in Access 2000 for serious development goes down hill
everyday. My checksum Version Control is my last attempt to live with
it, before resorting back to Access 97, which seems like a step
backward, on the other hand, things seemed to work so much better then.

Again - thanks a million.
Christine

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!