Changed by "Unknown" when using Changelog

aj131xaj131x Posts: 2
edited September 4, 2013 2:51PM in SQL Source Control Previous Versions
We are using SSC v3.3.1 in shared developer mode with SVN and have the changelog db set up to track who changed what.

But even though the RG_AllObjects table contains an entry for a modification to an object (table) and the correct username indicating who modified it, the "commit changes" tab shows the object as changed by "unknown".

It would appear that until we commit this object, whatever further changes we do to this object will not cause the "unknown" to be replaced with a username.

What we are finding is that many of our uncommited changes eventually end up with "unknown" against them as further modifications are made to the original object in areas that SSC does not currently support in change logging.

For example, a straight table creation will initially correctly show the user who created the table but a subsequent addition of a default constraint will cause the username to be replaced by unknown in the commit changes window (although the username will remain in the changelog table). All further table schema changes will not alter this situation until after the object is commited to our source control system (svn).

Could you explain this behaviour and specifically why when the username is corrrectly stored in the change log db, it is not appearing in the commit changes window? Thanks.

Comments

  • Eddie DEddie D Posts: 1,780 Rose Gold 5
    Hi

    Thank you for your forum post. I have created a support call for you, call reference is F0072780. From your post and I quote:
    For example, a straight table creation will initially correctly show the user who created the table but a subsequent addition of a default constraint will cause the username to be replaced by unknown in the commit changes window (although the username will remain in the changelog table). All further table schema changes will not alter this situation until after the object is commited to our source control system (svn).
    It looks simple enough to generate a reproduction, I will update this post when I have completed my investigation or require further information from you.

    If you have any further information that you think maybe useful to me, please update this forum topic.
    Many Thanks
    Eddie
    Eddie Davis
    Senior Product Support Engineer
    Redgate Software Ltd
    Email: support@red-gate.com
  • Eddie DEddie D Posts: 1,780 Rose Gold 5
    Using V3.4.0.103 of SQL Source Control I am unable to reproduce the error you have reported.

    I simply created a table and committed the change. My account name appears in the Changed by column.

    Altered the table I just created and added a Primary Key Constraint. When through the process to commit the change and again by account name is listed in the Changed By column.

    So I can try to reproduce the error, can you please send an e-mail to Support@red-gate.com with your call reference number F0072780 in the subject field of the e-mail. Please include the table script and alteration that you made, the contents of your RedGate_SQLSourceControl_Engine_EngineOptions.xml and any screen shots you can produce showing the fault symptoms.

    Many Thanks
    Eddie
    Eddie Davis
    Senior Product Support Engineer
    Redgate Software Ltd
    Email: support@red-gate.com
  • I'm not sure if this was ever resolved but I am able to reproduce this issue using SQL Source Control 3.4.9.265.

    I have created my own DB for tracking changes and modified the appropriate xml config file. The changes are being logged correctly and everything works for the most part except for a similar condition as the OP.

    I created a new stored procedure and the change appears on the commit tab with my username and is in change log. I did not commit the change and made a subsequent modification to the new procedure. This change also appears in the change log with my username but after refreshing the commit tab now shows changed by as 'Unknown' in grey text. I was able to reproduce this behavior with several procs.

    -Daniel
Sign In or Register to comment.