Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Modified dates in Access

Status
Not open for further replies.

JohnCHolmes

Technical User
Jun 25, 2002
59
US
Can someone tell me the location of the testicles of the Access designer who whimsically updates the "Modified" date? This is not just for compacting either, and not just on Reports, though those are the WORST offenders; only tables seem to be immune. So I'm looking for a fix - namely, the name and location soon-to-be-nontesticular designer(s) responsible. TIA.
 
What ever are you talking about? Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com
 
I have vividly endured this "feature." Perhaps he refers to some of these:
File/compact touches (or, as a real developer says, _destroys_) all report dates, at least; query and table dates may not be immune.

Opening any .MDB in Access destroys the system file date. Always. Always.

Open a query, change a field, save as a different name: this has an X percent chance of destroying the query date (I know that it has happened somewhat erratically to me, and I am completely careful, so it's definitely happening).

Other displayed date/times within a .MDB are destroyed in other circumstances too, the specifics of which don't jump immediately to mind, but others could add to this list, because I know that I've been burned myself, over and over.

This has been widely known and decried for at least a half a dozen - perhaps ten - years - yes, years. Maybe the developers will finally read what developers keep writing/saying, and wake up.

Clearly someone (or an institutional frame of mind) is clueless if they don't realize the needless damage of futzing around with file and database dates. Granted, you might be one that never looks at them, and wouldn't notice or care, but even then there is still no upside to the "destruction."

I don't know a remedy within Access. I, for one, would be willing to resort to [more! LOL] hokey workarounds if there is some way to limit or eliminate the damage. Does anyone have a trick? (I use Access 2000; is yet another update the answer?)
 
Are you using the latest SR. I have been using Access since 1989 and do not think i have ever encountered any of the problems which seem to plague the two of you.

For quite some time A2K had a reputation almost as bad as A95. Right after the release of A2K2, which is seen by most, inclding me, as THE FIX for A2K, MS released the big SR for A2K which really did seem to fix the rather extensive A2k bug list.

Sorry you seem to be having these problems, Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com
 
Just as a note here, I have A2K SR1, and a Compact/Repair done just now changes the date/time stamp on all objects EXCEPT tables and queries to the current date/time. I think this is what the prior posters are talking about, and is indeed a pain. I will have to try getting the MS Installer to update my Office2K to SR/2 and see if that fixes it, or does even more harm.

Trouble comes when developing at a client site where you may not have authority to update their versions. Even if the SR/2 "fixes" this, it's a problem that should never have happened.

Jim Me? Ambivalent? Well, yes and no....
Another free Access forum:
More Access stuff at
 
Jim,

I am currenty running both A97 and A2K2. A2K is on CD and right now I can't take time to reinstall to test this. Under A97, doing a compact changes no date; created or modified, on any object at all.

Doing the same using A2K2, there was a change to the date modified on both codeand class modules. The truth is, when you compact and or repair you are modifying all your objects. Arguments can be made of equal validity for either stand.

My personal observation is this an argument equivalent to Chicken Little. If you really have to track dates for purposes of which programmer is working on which aspect of which product you should be using Visual Source Safe, or, are you looking at this from a perspective i am not seeing. If so, please elaborate.

Thanks. Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com
 
No, I agree with you Bob, for real "source control" you should use a product like VSS - I'm just talking about the somewhat annoying practice of a compact operation that resets both the MODIFIED and CREATED ON dates (in the details view) of objects like queries and reports in a database. Sometimes, I like to sort by DATE CREATED or DATE MODIFIED in order to find that thing I was working on yesterday or whatever, and the compact and repair operation seems to throw a roadblock in that kind of process. This DID NOT, if my memory serves me correctly, happen in A97.

Jim
Me? Ambivalent? Well, yes and no....
Another free Access forum:
More Access stuff at
 
Jim,

What was interesting is that under A2K2 with the modules; the modified date did change which did make sense to me since compacting and repairing does modify all your objects, but the creation date did not change.

I have given up on tracking latest SR numbers, but rely on MS to tell me, and in this regard they have been very good. Are you positive you have the latest A2K SR?

Out of curiousity. If you are acquainted with using really nasty OCX's like Map Point, take a look at the thread Josh Peters has started on this thing and if you can, give him some input. I have a client who keeps threatening to want to do some drill down mapping, so, in case he really wants to pursue this, I am very interested in this thread.

Have a great day. Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com
 
Bob, I'm using Access 2000 SR1, as noted in my first post, so that might be why we appear to have different results here.

I have no experience with OCX's, and hope to shuffle off this mortal coil with the same.. LOL

I can see how doing a compact operation SHOULD change the MODIFIED date for things - I just don't agree with Microsoft that it should also change the CREATED date.

See ya around...

Jim Me? Ambivalent? Well, yes and no....
Another free Access forum:
More Access stuff at
 
>What was interesting is that under A2K2 with
>the modules; the modified date did change which
>did make sense to me since compacting and repairing
>does modify all your objects, but the creation date
>did not change.

Not to be difficult, but do you really mean that? How does compacting "modify," e.g., a report? Did I hear you right?! Or such that its date should reflect that a compact was done????? [Sarcasm mode off!] Sure, the ["DOS"] FILE date should change on a compact (as possibly will filesize); but no way the internal pieces.

It's like touching the file date of a .C file because it was recompiled. Of course, .the .OBJ and .EXE receive new file dates upon recompile, even if identical to before; but never, ever, should the source file be changed then. [rant off]

Anyway, C_VB_AccessDeveloper and WildHare do describe what I'm seething about. And thank you all for suggesting looking into the SR. Help/about has 9.0.2720 (no SR's showing there). From the sounds of some of the things I'm hearing here, I'm surprised I've lived as long as I have on this release!
 
John,

I do understand where you are coming from. I think the Access design team views objects within a database as individual entities, and from time spent dealing with this, I tend to agree. When you compact, objects get moved, written and rewritten. They have, in short, been modified. The creation date, at least on the version of A2K2 I am running, does not get changed.

MS's argument is this, if you compress a database in effect you are building a brand new database. If you put an object into a new database,has that object not been modified?

If you pay for the call, they will listen to your rant. Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com
 
If I didn't know better I'd say you're defending the modify date change, which is to say that there is a meaningful reason to reflect post- vs. pre- compact as separate. I know you can't be serious. Let me illustrate:

When you PKZip a file, does the .ZIP contain the zipping date on component files? After all, they're moved, written and rewritten, right? Now, really think about this one: How about on a zip refresh or update - WHERE NO SOURCE HAS CHANGED. Clearly we would agree that PKZIP would be laughed out of existence if they monkied with a perfectly valid date then. (In fact they even have a switch to ignore the date of the zipping, for setting the date on the .ZIP file.)

I hear where you're coming from too. Updating a ZIP file is not the same as collecting its contents and rewriting more concisely. But who in the entire planet of Bizarro would ever, ever care to see a new date on a table or report, just because a database was compressed? I can't believe I'm even saying this.

I'm rather horrified that there are developers that can even conceive this justification for changing the modified date IF THE SOURCE IS NOT CHANGED. I'm absolutely petrified that even outside of MS such may exist. After all, like was said up top here, information is destroyed.

The greatest shame is that there is absolutely no need to lose information from a compact. They could have saved it and rewritten it.

BTW nothing personal on you Robert. I can see you are greatly a net positive in this forum, and I'm always happy to help you out, once we return to the sane world ;)

> If you pay for the call, they will listen to your rant.
LOL. I'm rather hoping that someone out there reads Tek-Tips ROFL.
 
John (or should I call you Mr Wadd? LOL)

The MODIFIED date can be changed because compacting removes all the dead controls and garbage from a form/report that you stick on and then delete, or othewise mess with. It's my understanding, for example, that each time you "edit" an object like a form or report, the "prior shell" is retained, and the new guy just gets added to the heap of bits and bytes...

There used to be a limit to the number of "changes" you could make to a non-compacted database ( 32K sticks in my mind ) without the whole shebang blowing up in your face. I think I may have tried this once, by programmatically opening a form object and sticking a text box on it, then closing it, saving, and looping around.

After about 5 minutes of furious CPU activity and HD lights, the whole bloody machine froze solid-er than a penguins hemorrhoids...LOL..and the database had maxed out the Hard drive's TEMP directory.

Jim

Me? Ambivalent? Well, yes and no....
Another free Access forum:
More Access stuff at
 
All to often it is not what we know to be true, nor what we are told are the ramifications of what it is that we do say, but unfortunately, our reasoning is based on what we want treality to be. Things just don't work that way. This thread is a perfect example. To say or assume that compacting would not modify and that modification should not be noted...that is a "wish for" item. It does not have that much to do with what you produce and MS will give as much credibility to a wish list as it does to supporting either DAO or ADO.
We live with our tools or we change our tools.

Gentlemen, if ya don't like the tool, let me remind you....there are others. Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com
 
Thank you each for the polite discourse, and I'll refrain from insisting on the last word. (That's an impressive feat for me - my feeling on this is that I'm mushroom cloud-laying Jules in Pulp Fiction, a la
<<--warning, profane ). For your time, at least I'll turn you on to imdb :)
 
Jim,

Actually, it refers to a character on the first Star Trek series in the 1960's. A being who valued truth and logic above everything else. Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top