Dropped stored procedure gets re-added?
InspectorGadget
Posts: 5
Setup: Redgate on server, 3 developers using redgate to sync with server.
Scenario: User A drops a stored procedure, and commits changes. User B "gets latest" and gets the drop. User C "gets latest" and either the drop isn't coming through, or is failing without error. User C "commits" and the same Stored Procedure is being added back in.
It appears that the drops are not always flowing correctly. Has anyone else seen this kind of behavior?
Thanks,
--Glenn.
Scenario: User A drops a stored procedure, and commits changes. User B "gets latest" and gets the drop. User C "gets latest" and either the drop isn't coming through, or is failing without error. User C "commits" and the same Stored Procedure is being added back in.
It appears that the drops are not always flowing correctly. Has anyone else seen this kind of behavior?
Thanks,
--Glenn.
Comments
We have tested this with two of us several times. Whom ever does the drop propagates out the drop, and the other WILL see the drop when doing "get latest", but the drop doesn't fire. When "Commit changes" is selected by the second person, the stored procedure gets added back in.
Just to clarify, the problem seems to be this:
- a user deletes an object, goes to the commit tab, sees the drop listed and commits
- another user will go to Get Latest, see the drop listed, and then execute the Get Latest process. Although no errors occur, the object is still present in the database afterwards?
If so, that's a little strange. If the object couldn't be deleted i'd expect an error to occur.
Does this consistently occur with all users and objects? Or is it intermittent?
Are you using Migration scripts at all?
Are you using Shared/Dedicated mode?
What level of access do the users have to the database that's linked? Does the same thing occur if they are 'sa'?
Redgate Software
Seems to be happening to all functions and stored procedures. Will test triggers to see if it is working. I am not willing to say that it is NOT intermittent, as we were running RedGate for a week or two before I noticed this behavior.
Began looking at the login we use to access our local copies. It appears that the user tied to the database had become unlinked from the login for the instance. After deleting the user, and then recreating it from the login, everything seems to be working.
It still bothers me that there were no errors. There should have been a message or something that said the drop was not allowed or something.
Thanks,
--Glenn.
I'd agree there should have been errors. When you do a "Get Latest" it's basically executing a script for any changes, such as the drop, or creation of new objects. If this was failing due to a permissions issue, then i'd expect the script to fail which will normally be visible via the Get Latest progress dialog.
I'll let the Source Control team know and they can see if they can replicate it at this end.
Redgate Software