Dropped stored procedure gets re-added?

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.

Comments

  • After more testing, it appears that the drop from "get latest" is not actually happening. There is no error reported.

    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.
  • Confirmed. We are getting the "drop" on the "Get Latest", and after the "Get Latest" button is pressed, all shows clear, however, the SP or FN still exists. Tried this with several different FN/SP.
  • Thanks for your posts, and sorry you're having trouble.

    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'?
    Systems Software Engineer

    Redgate Software

  • Your synopsis is accurate.

    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.
  • Thanks for your reply (and glad it's working now!)

    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.
    Systems Software Engineer

    Redgate Software

Sign In or Register to comment.