"Unknown" Changed By Field
SteveGTR
Posts: 91
We're doing our initial tests and we've been getting "unknown" changed by fields almost as a rule.
1) User A signs into SSMS using a SQL login account
2) User A changes a stored procedure
3) User B signs into SSMS using a SQL login account
4) Goes to Commit Changes page and the change User A made is annotated as "unknown"
5) User C signs into SSMS using Windows Authentication (to see if this works better)
6) User C changes a stored procedure
7) User A and user B go to the Commit Changes page and the change User C made is annotated correctly (change by is User C's account)
8) User B is in SSMS and goes back to Commit Changes page and clicks the refresh button
9) Now User C changes have the "unknown" changed by field
10) User A sees the same thing
I've seen the posts regarding setting the frequency of the RedGate polls, etc... I'm getting this by hitting the refresh button, so I'm manually polling the system.
Thanks
1) User A signs into SSMS using a SQL login account
2) User A changes a stored procedure
3) User B signs into SSMS using a SQL login account
4) Goes to Commit Changes page and the change User A made is annotated as "unknown"
5) User C signs into SSMS using Windows Authentication (to see if this works better)
6) User C changes a stored procedure
7) User A and user B go to the Commit Changes page and the change User C made is annotated correctly (change by is User C's account)
8) User B is in SSMS and goes back to Commit Changes page and clicks the refresh button
9) Now User C changes have the "unknown" changed by field
10) User A sees the same thing
I've seen the posts regarding setting the frequency of the RedGate polls, etc... I'm getting this by hitting the refresh button, so I'm manually polling the system.
Thanks
Comments
"The default trace is a very powerful way to examine the health and the security of your SQL Server instance. There are several pitfalls to keep in mind – mainly related to file rollovers and size limitations, but with some programming the workarounds are not impossible. It is important to remember that the queries presented in this article will return the result from the single most recent default trace file. Depending on how busy the SQL Server instance is, the files may roll over way too fast for a DBA to catch all significant events; therefore, some automation is needed."
You've hit the nail on the head. The default trace rolls over and the information goes with it. We're in the process of optimising how we use the default trace to ensure it rolls over less frequently. We'll post to this thread as soon as we have a build for you to try out.
Thanks for drawing this to our attention.
Kind regards,
David Atkinson
Red Gate
Product Manager
Redgate Software
Thanks
David
Product Manager
Redgate Software
It's hard for me to understand how this product can be used in a multi-developer environment when the changed by field goes out of scope (becomes "Unknown") in such a short time frame. In our case, 15 minutes and all the pending changes come up as "Unknown".
Why RedGate would implement such an unreliable technique as the default trace for the changed by field is beyond my comprehension. Maybe someone could explain it to me.
Thanks
Thanks for your question. The reason the default trace is used is because it is enabled by default (thereby requiring no additional configuration) and supplies us with the information we need. The challenge is that the default trace will roll over, and for some users too quickly. 15 minutes is very quickly.
We're currently investigating alternatives, including persisting this in our own data store. The drawback is that this requires DBAs to administer yet another database, which is an implementation that could be too intrusive for some, but it could be the only option.
I hope this answers your question. We'll be aiming to release on a more frequent cycle, so hopefully we'll be able to further improve what is understandably a popular feature.
Out of interest, what is the reason you are choosing a shared development environment over dedicated per-developer ones?
David Atkinson
Product Manager
Red Gate
Product Manager
Redgate Software
I'm actually looking for a response from someone who uses your product with the shared database model in a team environment.
In addition, I like that other developers can see what is being worked on by other developers.
That is why the "Unknown" changed by bug is so important to me.
In a perfect world the source control system we used would:
1) Manage the SQL scripts automatically for us --- RedGate does a great job with this
2) When someone is working on a SQL object others developers should be able to see that they are doing the work --- RedGate's shared model should do this, but the "Unknown" bug is causing this to fail
The reason why I feel it is important to communicate when a change is being made is because stored procedures don't merge well when two people are working on them at the same time. If someone sees that another person is working on a SQL object they can work more carefully. This avoids duplication of effort, wasted effort, and errors.
Don't get me started... oh! Too late
I added an SP this morning and within three hours "I" became "Unknown". There's NOBODY ELSE on the server - I'm the ONLY DB Developer... There are a few background jobs acquiring fresh data from Production but they're only actually creating rows on 5 of 60 executions per hour.
I wouldn't expect MY default trace file to roll-over in just 3 hours!
In my case, as I'm "it", I know whodunnit, but it is still a BIG BUG crying out for a rapid fix (IMO).
When, please?
Decide wisely...
We use a shared dev environment because the database is too large to replicate for all the developers (well over 500GB.)
Your question makes me wonder if the shared development model is not as well supported or implemented as the per-developer model...
Could you potentially use a db trigger to detect changes to the database?
Here's a sample trigger I wrote once to audit db changes to a table...
Is there a way to vote on issues to change priority? It's not transparent to us users which issues are higher on your list and when the expected release is.
Thanks,
Michael
Yes, just click the little feedback link in the tool itself!
Or go here: http://redgate.uservoice.com/forums/390 ... ce-control
We have a feedback site where you can vote for changes you'd like to see in the product called UserVoice. There is already an entry for the ChangedBy = Unknown issue, which you can vote on.
In terms of priority - this is something that we are looking at right now. We want to make sure that our solution meets the requirements of as many users on the Shared Model as possible and have consulted a number of you regarding how best to do this. However, this feedback has indicated that we need to make a more significant change than we originally envisaged, so we don't expect to get the solution out until Q2 (2012).
I'll update this post when we have news on an Early Access or Release build that includes this work.
Best regards,
Chris
Redgate Software
He posted an "admin" link to the page (I think, accidently...)
The correct link for us users is:
https://redgate.uservoice.com/forums/39 ... -says-unkn
Redgate Software
David Atkinson
Red Gate
Product Manager
Redgate Software
An Early Access Release of SQL Source Control v3.1 is now available that includes a solution to the 'Changed by = Unknown' problem.
For more details, and a download link, please see:
http://www.red-gate.com/MessageBoard/vi ... hp?t=15345
Thanks,
Chris
Redgate Software