GoldMine Time Bomb Triggered in 2011

Mark Berry January 8, 2011

GoldMine Date Issue 1 When I started GoldMine 6.5 for the first time in 2011, I was greeted with a rather unwelcome message:  “Please note that your computer’s system date is erroneously set to 1/1/2011. GoldMine’s synchronization may not function properly unless the system date is set correct. Would you like to correct the system’s date now?” If you press Yes, the Date and Time Properties open so you can change the date. But the date is correct!

Today I found a relevant and very helpful thread on FrontRange Connect. I’ll highlight some posts in that thread and add a few thoughts.

Note:  dates in this post are in MM/DD/YYYY format.

Where Did That Message Come From?

I found this in the release notes for GoldMine 4.00.9626, dated July 1, 1999:

“New:  GoldMine now checks for a reasonable system date (03/01/1999 – 01/01/2011) upon startup, warning users if there is a problem.”

So apparently we have now reached the end of reasonable dates for using GoldMine 4.0. However the check was not removed until much later—according to PaulRogers001’s post on 1/3/2011, the error message persists through version 7.0.3 (build 7.00.60526, release notes updated June 5, 2006).

Will Synchronization Work?

If you respond No to the message, you can continue using GoldMine without apparent issues. You can even use a hex editor to change gmw6.exe and suppress the message (in the same thread, see Aharry’s post on 1/4/2011). But that leaves the question, is there really a risk that synchronization will no longer work?

On 1/3/2011, ptools1 posted an “informal, non-official, non-binding” response from an email exchange with FrontRange support:

This seems to only be an issue with our Goldmine 6.7 and lower. We have not a fix for this issue but it has been sent to development to review. As this is a version that is no longer supported I find it unlikely that we will be release a patch.

The error message I know mentions that is may cause issues with syncing, but thorough testing shows that everything is working as designed, by clicking yes (sic) to the error message you will continue to have full range of the product.

Well that’s encouraging, but I’ll feel better if I check a few more things.

Old RecID vs. New RecID

I wondered if there was some relation to the conversion to the “New RecID”, but that was introduced with 4.0.811 on August 14, 1998, almost a year before this date warning was added. After reading a detailed explanation of the RecID change, it seems that change pertains strictly to eliminating special characters from the sorted fields in the sync tables. Dates are not mentioned.

AccountNo as Date

The first six characters the the Contact1.AccountNo field store the date the record was created, e.g. 991229 for a record created 12/29/1999. However, a quick check of my database (Lookup > Indexed Fields > Account No) shows that GoldMine switched to letters in 2000, e.g. A00105 for a record created 01/05/2000, A91215 for 12/15/2009. Starting in 2010, AccountNo’s begin with “B”; my most recent record starts with B10106 for 01/06/2011. With one letter per decade, that should be good for another 249 years or so.

The GoldMine SyncStamp

In my opinion, the real potential for a date limit is in the synchronization data. GoldMine 6.5 stores most sync data in two tables, ContTLog (for data specific to a contact database) and GMTLog (for “GMBase” data generic to all contact databases). Both of these tables have the same structure:

SYNCSTAMP Char 7
LOGSTAMP Char 7
ACTION Char 2
TABLEID Char 1
FRECID Char 15
FIELDNAME Char 10
USERID Char 0

It’s the SyncStamp and LogStamp fields that concern me. Each of these compresses a date and time, down to the second, into only seven characters. According to an old INI-files.doc document I unearthed, a SyncStamp also comprises the first seven characters of the record’s unique RecID. So is there some concrete date limit on how far into the future a SyncStamp can go?

I have an old copy of SyncSpy, not the one included in GoldMine, but standalone version 1.09.2099 from 1998. In this version, if you select File > Stamp Converter, you can convert arbitrary dates to SyncStamps and back. Assuming the SyncStamp algorithm hasn’t changed, this should be a good way to check some dates and make sure GoldMine can handle them.

GoldMine Date Issue 2

The first test looks good:  my newest record was created 01/06/2011, which gives a SyncStamp of F8EI4RE.

GoldMine Date Issue 3

It appears that SyncStamps are chronological when sorted alphabetically. How far forward (and backward) can we go? (SyncStamps are in the format YYYYMMDD:HH:MM:SS.)

0000000 19891231:16:00:00  
YTTTTTT 20380118:06:06:21  
YTTVVVV 20380118:06:38:21  
YTUVVVV 20380118:15:58:13  
YTUZZZZ 20380118:17:02:12  
YTV8HDR 20380118:19:14:07 greatest value that does not generate an error
YTV8HDS <error>  

So it would appear that SyncStamps can accommodate dates from 12/31/1989 to 01/18/2038. But what about the reverse?

20380118:19:14:07 0000000 uh oh, it’s not showing an error, but it’s not converting back to a reasonable SyncStamp
20380118:11:14:07 YTUDM8E greatest value that does not return 000000
20380118:11:14:08 0000000 first value that returns 000000

Let’s step down through some more likely dates, July 1st at 3pm in different years:

20110701:15:00:00 FKZ9BK0
20120701:15:00:00 GB4M7K0
20150701:15:00:00 IHCZ3K0
20200701:15:00:00 M3W1RK0
20300701:15:00:00 TCT1WW0

That all looks pretty reasonable. It would appear that SyncStamps can handle dates into the 2030s.

Update 01/13/2011:  Wikipedia’s article on the Year 2038 problem, although it doesn’t mention RecIDs, would seem to confirm the 2038 boundary. Thanks to Darren Lawrence’s post today.

Update 12/29/2012:  According to this thread, a sync stamp is “the number of seconds from 01/01/1990 till the creation of the new record + the GMT in seconds.” The thread includes Basic and SQL code for converting sync stamps to the date and time. Haven’t tested this myself, but it could be an interesting starting point if you want to code your own sync stamp converter.

Conclusion

Apparently, the check for a reasonable system date added 22 12 years ago was meant merely to warn you that an incorrect system date can confuse synchronization. That’s still true today. (I would not be surprised if a user had called support because their system date was way off and it was messing up their synchronization. Didn’t computers used to default to 1/1/1900 if the CMOS battery died?)

In any case, as best as I can tell, the warning message is not an indication that synchronization will no longer work after January 1, 2011. However, I’m just an end user trying to guess at this by examining the system. It would still be helpful if FrontRange would check the code and officially confirm that even their older products will continue to work for years to come.



7 Comments

  1. Apache   |  January 10, 2011 at 3:51 pm

    I hope so. I am a lover of my goldmine 5.5 dbase version.
    The time is a Damocles Sword over all old versions.
    I think Frontrange will take a look and say something. Or the splendid equipment that informs in the forum will give an “unofficial” answer.
    Thanks
    Excuse my language. I’m from Canary Islands

  2. Henning   |  January 12, 2011 at 7:27 am

    see solution posted by “GoldMineDataDiva” Jill on http://www.castellcomputers.com/contactreview/phpbb2/viewtopic.php?t=1595&postdays=0&postorder=asc&start=15&sid=f64adb2360676dbd2b3074ef434fc175

    “Here is another crazy fix from GoldMine forum: not verified but sounds reasonable: This is a very easy patch with any hex editor. Find a free hex editor ( I use HxD from http://mh-nexus.de/en/downloads.php?product=HxD) Load GMW6.EXE and do a text search for 20101231 change the 2010 to 2020 and save the file. No more warning (at least until 2020! Of course, you should back up your GMW6.EXE file before editing.. and you do this at your own risk although it is very simple I am not responsible if you mess something up. And this also will not remedy any issues that may have been lurking that the developers felt they needed to warn against in the first place.. if there are any. ”

    worked for me on Goldmine 6.5 :-)

  3. Mark Berry   |  January 12, 2011 at 9:05 am

    Yes, that’s the hex edit that I was referring to in the second sentence under “Will Synchronization Work?” In fact, you don’t even need a hex editor: I used Find and Replace in Notepad++ (http://notepad-plus-plus.org/) and it worked fine. Just make a backup of the old .exe before modifying it.

  4. JD   |  February 22, 2011 at 9:03 am

    I’m pretty sure 1999 was only 12 years ago, not 22 as the conclusion suggests.

    A 22-years-from-now date check could be considered ‘sane’ since techonology that old should not be in widespread use. 12 years however is a bit short!

  5. Mark Berry   |  February 22, 2011 at 9:38 am

    Well THAT’s’ embarrassing! I guess it just feels like 22 years :)

  6. Perry   |  April 05, 2013 at 1:27 pm

    I have been using Goldmine Standard V. 6.50.31113 since it was new. My 10-year old PC running XP Pro is in its last throes, and I obtained a new PC with Windows 7 and would like to obtain the latest and greatest Goldmine has to offer. However, I heard a rumor that my 6.5 data will not work with the latest version (9.2?). Whadamigonnado?

    P

  7. Mark Berry   |  April 05, 2013 at 8:47 pm

    There is a somewhat cumbersome upgrade path–first to 6.7 (easy), then to 9.0 (not so easy), then beyond. I believe support will provide 6.7 and 9.0 after your purchase. Your GoldMine 9.x purchase should include support; in fact, they might take your call if you have pre-sales questions like this. I would also consider working with a reseller who has been through this before.

Leave a Reply





*