Apparently this is a known problem in version 4 (see
http://www.red-gate.com/MessageBoard/vi ... procedures), but I am raising the issue again because of its importance.
I just spent an hour trying to figure out why SQL Compare was doing the wrong thing. After studying the scripts it generates, and after searching these forums, I see the problem:
1. I used Microsoft SQL Server Management Studo to rename "spAddNewAccount" to "spAccount_CreateAccount"
2. SQL Compare detected the difference and emitted this script:
DROP PROCEDURE [dbo].[spAddNewAccount]
PRINT N'Creating [dbo].[spAccount_CreateAccount]'
CREATE PROCEDURE [dbo].[spAddNewAccount]
I understand that the root of the problem has to do with Microsoft allowing the database to enter an inconsistent state after use of sp_rename, but if SQL Compare cannot deal with the problem is should detect it and WARN users that the product cannot handle rename. Generating the script above is simply wrong.
I just spent an hour trying to figure out why SQL Compare was doing the wrong thing. After studying the scripts it generates, and after searching these forums, I see the problem:
1. I used Microsoft SQL Server Management Studo to rename "spAddNewAccount" to "spAccount_CreateAccount"
2. SQL Compare detected the difference and emitted this script:
DROP PROCEDURE [dbo].[spAddNewAccount]
PRINT N'Creating [dbo].[spAccount_CreateAccount]'
CREATE PROCEDURE [dbo].[spAddNewAccount]
I understand that the root of the problem has to do with Microsoft allowing the database to enter an inconsistent state after use of sp_rename, but if SQL Compare cannot deal with the problem is should detect it and WARN users that the product cannot handle rename. Generating the script above is simply wrong.