dbtran 'connect' comment date format

[Former Member]

We have recently upgraded from version 12 to 17, currently running 17.0.4.2100.

I have a routine that uses dbtran.exe to translate a transaction log file to SQL, then (roughly) greps out the 'connect' comments that are included in the SQL and extracts the date the connection was made from part of the comment string.

In version 12 these comments were of the form:

--CONNECT-1049-02294397649-"foo"-2016-09-05 14:59

but in version 17 the year of 2016 is actually written as 3616:

--CONNECT-1023-0017293072-foo-3616-09-05 14:33

it's also interesting that version 17 writes 'COMMIT' comments in a similar format but in this case the year is written as 2016:

--COMMIT-1023-0017293583-2016-09-05 14:33:36.657

Is this expected behaviour? If so can I simply take 1600 off the year from the comment to get the actual year or is the calculation dependent on some other variable?

[VolkerBarth]

If so can I simply take 1600 off the year...

No, it's more complex, you have to subtract the full version number of the previous version but without the build number (here 16.0.0).

Just kidding:)

And you have noticed an interesting change...

---

FWIW, I have reproduced that with older v17 versions: The CONNECT comment from the v17 GA version and from 17.0.4.2053 do also display the year with an irritating "1600" added, such as

--CHECKPOINT-0000-0001164831-2015-07-28 12:15:33.478
--CONNECT-1001-0001164861-DBA-3615-07-28 12:16
....

v16 does not show that strange behaviour...

[Vlad]

No, it's more complex, you have to subtract the full version number of the previous version but without the build number (here 16.0.0).

I don't have other comments, but wanted to say, this one was funny 🙂

[regdomaratzki · Accepted solution]

This is a bug that was introduced as a side effect to the changes made for the Point-In-Time Recovery feature that was added in v17. For now, you can just subtract 1600 from the year in the dbtran output, and a fix is forthcoming in the near future (which is slightly more complicated than simply subtracting 1600 unfortunetly).

[Edit: Sept 27, 2016] The aforementioned near future has arrive. This issue should be resolved in v17 build 2176.

Reg

[VolkerBarth · Accepted solution]

which is slightly more complicated than simply subtracting 1600 unfortunately

Yep, as I said *"No, it's more complex, you have to subtract the..." 🙂

[Breck_Carter · Accepted solution]

Beta testing always happens, it cannot be avoided 🙂