Link to home
Start Free TrialLog in
Avatar of LJG
LJG

asked on

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
LJG
User generated image
Avatar of Jim Dettman (EE MVE)
Jim Dettman (EE MVE)
Flag of United States of America image

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?

Jim.
ASKER CERTIFIED SOLUTION
Avatar of PatHartman
PatHartman
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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.

JeffCoachman
Avatar of LJG
LJG

ASKER

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.