Modified Date - module - Access 2010 - Dates don't match

Question: I'm trying to figure out how to get a "Modified Date" for modules in Access 2010.
If you look at the graphic you will see
            MySysObjects and the Property Form show the same Create Date.
            MySysObjects and the Property Form show the Different DateUpdate  / Modified  Dates.

If I change code in the module – the property form Modified Date is correct – the MySysObjects DateUpdate is wrong.

            Just 2 side notes:
1)      If you compile the code (no changes just compile) – the property form Modified Date changes to date/time compiled
2)      I compacted/repaired the db and the MySysObjects DateUpdate do not change.

Thanks for any help
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
The problem is they are two different things and the internal process of what gets updated when has never been made public.

 In the past, there also were bugs in this area where the dates were not updated correctly.   I guess the real question is, what's the end goal?  Source control?

I long ago gave up on getting accurate change information for modules.  Access changes the date on its own schedule, not when I think it should be changed.  It also changes the date for the file if you simply open it.  The DateUpdate in the MSysObjects table seems to match the DateCreate in the database I am looking at.  But in the Nav pane, the Date Modified changes for all modules if I change any one.  I haven't tried using the collections to see what they say.  Please post back if you actually find something useful.

I use this query to populate my application last changed date on my menu.  If I change a module, I try to remember to change one of the object types below so my date gets updated.

SELECT Max(MSysObjects.DateUpdate) AS MaxOfDateUpdate
FROM MSysObjects
WHERE (((MSysObjects.Type)=-32768 Or (MSysObjects.Type)=-32764 Or (MSysObjects.Type)=5 Or (MSysObjects.Type)=1));

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<I long ago gave up on getting accurate change information for modules. >>

 Can't second that enough.  

 Stuff a date in a table and use that.  Of course you need to remember to change it.   Pat's method is very nice in that it gets around that, but personally I'm loath to rely on anything internally in Access in this area having lived through the bugs.

 At one point it was so broken, you couldn't use the dates for anything.  Even Microsoft gave up on source control with Access early on.  Although to be fair, multiple developers working at one time on an app is not as widespread with Access as it might be with other products.   So it was a lot of effort for very little return, but the bugs didn't help either.

Jeffrey CoachmanMIS LiasonCommented:
what's the end goal?
Source control?
I Agree with Jim and Pat,...
I thought it would be cool to have a listing of each object, and when it was last "updated".
After having the same experiences as the previous experts, I realized that doing this was not as imperative as I had thought.

I am almost always the only Access developer, and I employ split databases, and multiple backups.
Pretty much anytime Access asks to save changes, I make a backup.
(Obviously, this sometimes leads to me having a mountain of backup files, ...but I try to be religious about cleaning up old/obsolete/un-needed backup files)

So in this case, I can always go back to a previous version of the database.

Typically (in a mature database), the developer will have a fairly good idea of when they made a change, and to what object.
So (for me), the exact date and time is rarely needed.
If I get too bogged down, I will simply revert to the previous version.

I also try not to make too many changes at once.
I make one change, test it and make a backup.
The make another change, -->test it and make a backup.
...and so on...
This way if something fails, I need only revert back one version.

LJGAuthor Commented:
Thanks guys I learned something today.  

I do work on lots of apps and make changes to generic objects all the time.  Sometimes I worked on an app a year ago and I need to know what the most current version of a Generic Object.  

Below is my way of keeping track of Generic Objects.  I'm not saying it's the best, but it works for me.

1) On all Generic Objects I put a version # (See the above graphic --Description -->This is version 10.12 of mod_BC)

2) Any Generic Object that has code I put in what has changed.
      'ver 10.12  - 05/12/2015 -  --> No Changes ----> Just wanted a note
      '                               -->If you are using --> mod_bc.frmIdToTable_Server you need to go into all lookup forms and change Where_SubQuery() to --> public

      'ver 10.11  - 04/24/2015 -  --> Fully backward compatible to v10.09
      '                               Minor Changes --> sec_Chk_Open_Frm_Rpt()
      '                               Minor Changes --> frmIdToTable_Server()

      'ver 10.10  - 02/09/2015 -  --> Fully backward compatible to v10.09
      '                        Added --> OutLookSend_Multiple_Files()
      '                        Added --> dbSys_PauseForSecounds()

3) I have a process that goes through all objects and looks at the Description.  If no Description it ignores the object, otherwise it presumes it's a Generic Objects and puts the object name with the version (Description) in a table.  Then it puts that info (along with the db name) in a database I use for all my projects.  
I then can run a report that shows my Generic Objects in the current db compared to all my other projects, and I know where the latest copy of the object sits.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.