User profile for SteveGTR

We are choosing the shared environment because it reflects how we currently work. 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 [image] / comments

We are choosing the shared environment because it reflects how we currently work. In addition, I like that other developers can see what is being worked on by other developers. That is why the "Unk...

0 votes

Thanks for the reply David. I'm actually looking for a response from someone who uses your product with the shared database model in a team environment. / comments

Thanks for the reply David. I'm actually looking for a response from someone who uses your product with the shared database model in a team environment.

0 votes

I give up... Does anyone use the shared database model? If so, how are you handling the "Unknown" changed by problem? 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 [image] / comments

I give up... Does anyone use the shared database model? If so, how are you handling the "Unknown" changed by problem? It's hard for me to understand how this product can be used in a multi-develope...

0 votes

Does the prior release (before version 3) exhibit this problem? I'm looking at ways to use your software. As it is, this bug is a deal breaker... / comments

Does the prior release (before version 3) exhibit this problem? I'm looking at ways to use your software. As it is, this bug is a deal breaker...

0 votes

I'm at a loss of what to tell our implementation team with regard to this issue. When can we expect a fix? Thanks [image] / comments

I'm at a loss of what to tell our implementation team with regard to this issue. When can we expect a fix? Thanks

0 votes

I repeated the test using a SQL login account and the changed by field appears for a time and then disappears, transformed into "unknown". / comments

I repeated the test using a SQL login account and the changed by field appears for a time and then disappears, transformed into "unknown".

0 votes

I see now what all the talk about the default trace is now. I've been monitoring our trace file and can understand why the changed by fields are being displayed as unknown after some time. The trace files are restarted after a time and new information is captured. This paragraph from http://www.simple-talk.com/sql/performa ... -auditing/ sums up the problem well: "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." / comments

I see now what all the talk about the default trace is now. I've been monitoring our trace file and can understand why the changed by fields are being displayed as unknown after some time. The trac...

0 votes

"Unless we instrument SQL Server with additional DDL triggers, something that users have said would be unacceptable..." I don't understand why users would find this unacceptable. Aren't there already triggers in affect? I'd think you would just be extending the existing triggers. In any case, if users want more control of this functionality perhaps an administrative settings console where these options could be controlled would satisfy the users that find this unacceptable. When we were evaluating your software one of the things I found amazing was that when I changed an object (via SSMS) on a machine that didn't have RedGate Source Control installed, it showed up as a pending change on the machine where I had your software installed. "The best we could hope for is for the lock to be advisory. Would this be good enough?" I don't understand what you mean by "advisory" in the context of the above sentence. "When using a dedicated model, you won't be able to overwrite another's changes unknowingly as a conflict will occur, and the tool will let you decide which object you want to take. Is this something that would work for you?" Now that's what I'm talking about! I shouldn't be able to simply overwrite a pending change made by another user in dedicated or share models. Saving a log of changes would be very helpful when we discovered there was an overwrite. I'm hesitant to look at this as a solution because overwrites are hard to detect if the change was subtle. It might be months before you discover that a change wasn't applied. By that time the log may be way out of date. But it is helpful if you spot it in a timely manner. If you took the stance of warning or preventing changes to objects that currently have pending changes by another user I think that would be an outstanding step in the right direction. Thanks [image] / comments

"Unless we instrument SQL Server with additional DDL triggers, something that users have said would be unacceptable..." I don't understand why users would find this unacceptable. Aren't there alrea...

0 votes

Thanks for the reply. This point really scares me in that its just what we are trying to avoid by using your product. I can even see this sort of thing happening in a dedicated server mode. What is the rationale for not checking out the stored procedure or any existing object when the user changes it in the share database model? The same would apply to the dedicated model. Communications of what we are working on among team members would be doom to failure... That is one of the reasons for source control, communications. When I see someone has something checked out I tread carefully or ask. If I see nothing, then I'm on my merry way. Even an option from within your snap-in to checkout an object would be a plus. Then we could say please check the object out first when doing changing. In any event, your product is a huge step in the right direction for our team and I hope that some of these holes can be plug to help prevent mishaps. / comments

Thanks for the reply. This point really scares me in that its just what we are trying to avoid by using your product. I can even see this sort of thing happening in a dedicated server mode. What is...

0 votes

I was thinking even with a dedicated database, what communicates to another developer that you are working on a stored procedure? / comments

I was thinking even with a dedicated database, what communicates to another developer that you are working on a stored procedure?

0 votes

How can we help you today?

SteveGTR

Comments