On a shared model, the Changed By column says unknown for some uncomitted changes on the Commit List
When I try to commit changes it says unknown user. I believe it is very important to be able to track who's making what changes.
In v3.1, we store user information when an object changes so you don’t see “unknown” on the commit list for changes on a shared model. Details are at https://documentation.red-gate.com/display/SOC32/Logging+changes+to+shared+databases
J. Verdurmen commented
With 3.1 this is still a problem.
Now, I got permissions to run 'SYS.TRACE', but get a new error that simply says: "The user does not have permission to perfom this action", but it doesnt say what the action is. It is obvious that it still does not perfom as intended. The whole purpose was to be able to tell who last modified an object without being a sysadmin. This is not near ready for prime time. Uninstalling.
I got an admin to install the new version so it created the RG database, but now I receive a new error: Cannot alter database, etc. So I got full rights to the RG database (coudl not access it), now I get a new error: You dod not have permissions to run 'SYS.TRACES'.
I installed the v3.1 version, and launch management console, but under the Commit Changes tab, I receive the error:
CREATE DATABASE permission denied in database 'master'
Jason Taylor commented
*cilck* I get it now. That makes a lot of sense. Thanks!
AdminChris Smith (Admin, Red Gate) commented
The RG database is providing pre-commit information that is displayed in the “changed by” field on the commit tab.
Once a change has been committed we display the details of the user that performed the commit in the History dialog, and this information does come from the version control system.
Jason Taylor commented
Why a whole new RG database to record who made the commit? I know subversion itself can store that information. Is there a supported source control backend that can't?
Arthur Blake commented
Have you thought about using a database trigger to detect changes? Seems to me like it would be a lot faster and more reliable than polling the default trace.
The only downside is that you have to modify the underlying db to do this (although the modification is very minor...)
See my comment in http://www.red-gate.com/MessageBoard/viewtopic.php?t=14555
Stuart Davis commented
I'm dumbfounded you are on version 3 of this product and the Changed By column just shows "unknown"!
Using the shared model, this is absolutely critical for the product to benefit us. Out of 100 changes made by the team to a database since my last commit, I don't know who has uncommitted changes or what the changes are I need to commit myself.
Undoubtedly it's not straight forward as more than one user could have touched an object between commits, but at the very least I'd want to know who made the most recent uncommitted change.
Ideally I would like to filter the list of changes by who caused them or at the very least be able to commit only my changes.
Please let us know when this is available, so we will be able to use this module. (product).
Tim Berg commented
This is critical for historical code reviews and who is responsible for what.
Jason Wallace commented
This is really important for us - it could be a huge benefit to know who is working on what changes.
The way this was implemented is a complete hack job. You guys can do better than this, i know you can. The way it needs to be implemented is by using the Source Control repository's native check-in / check-out functionality. This will open up your options to track changes for other db's such as Oracle, MySQL, etc...
Misty Swearengin commented
We working on a shared database and have several developers who are updating the database at any given time. We need to be able to understand who is making changes and why the changes have not commited to source control. Because the Changed By user says unknown, I have no insight into who made a change and did not commit it to source control. We need to know this information in order to manage source control and ensure it is being used properly.
AdminDavid Atkinson (Admin, Red Gate) commented
@Will - Thanks for the feedback. Over the next few weeks we hope to experiment with an improved technique to preserve the modifier for longer than occurs right now. Please bear with us!
We do a lot of work and wait a long time before committing changes. In our environment, it's crucial to be able to tell who made changes before they are committed and promoted to the next environment.
Remi Mongeau commented
It would be very nice having a "strong" information for the ChangedBy column. The good usernames appear for only about an hour here, after that it turns to "unknown" which is not very user-friendly when it times to commit changes.
Stephanie, Yes I understand this but if you are working in a large team and you go to commit your changes there may be many other changes from other people, you then have to spend the time double checking that the changes that you are about to commit are yours, also makes it hard to determine who has made other changes if you wish to contact them to discuss. Not all changes are going to be committed straight away so you end up with a mix of changes that at some point need to be commit but have come from many different people and hence in this case “Unknown” provides very little help.
Sorry if I am pointing out the Obvious or missing the point :0)
Thanks for your reply.
Sorry but I think that it is rather poor that "Unknown" shows. The whole point of using the shared model is to be able to see who has made what changes as a way to manage updates back to the source control. I don't quite see the point in having the shared model if unknown is always going to show?
If your default trace rolls over a lot and you are always seeing "unknowns," then you could try 2 things:
1) Change your polling options so the blue indicators are less frequent. This would create less entries in the Default Trace. There are instructions on how to do this at http://www.red-gate.com/messageboard/viewtopic.php?t=12837. Each user would need to do this since these settings are a per user (per machine) option.
2) Close SSMS more frequently. Polling will continue to happen for every db under source control that you touch in a session and will not stop until SSMS is closed. Therefore, if you are no longer actively working against the db, you may want to close SSMS.
Keep voting here if we should implement our own trace so "unknown" isn't shown as often. If implemented, this is something you could opt-in to. Let us know how you would feel about having an additional trace on your development db servers.