User profile for Bogdan Iosif

Thank you for your support, I will consider the matter closed. / comments

Thank you for your support, I will consider the matter closed.

0 votes

Hi Brian, Thank you for your help. I understand the fact that there is no option for partial code comparison using case sensitivity/insensitivity and I never expected this behaviour. Please, let me explain one more time the problem I encountered. Step 1. In SQL Compare, select two dbs for comparison & synch. They have some different objects, amongst these being a few that I will call FunkyDbObjs. The reason for the name is this: The objects themselves are identical but the SQL script for the objects is different only by the case of the CREATE statement. SQL Server stores in the syscomments table this object definition for any object currently in the server. For example: In the REFERENCEDB's syscomments table, the definition for a stored procedure is: "CREATE procedure [dbo].[uspLoan_ContractComputeCommission] ....." In the TARGETDB's syscomments table, the definition for the same stored procedure is: "creATE procedure [dbo].[uspLoan_ContractComputeCommission] ....." The two stored procedures are otherwise identical. Step 2. In SQL Compare, check the case-sensitivity option for comparison, with every other option remaining at it's default value. Step 3. Compare the two databases. SQL Compare will correctly identify that the FunkyDbObjs are different in the two databases, based on their different by case, creATE/CREATE statements, extracted from the syscomments definition tables. Step 4. Run the synch wizard. SQL Compare generates the synchronization script for the FunkyDbObjs. This script will contain ALTER PROCEDURE statements to modify the FunkyDbObjs in the target db. -- Here comes the SQL Compare problem -- When ALTER PROCEDURE is executed, only the body of the FunkyDbObjs will be refreshed in the TARGETDB's syscomments table, leaving the creATE statement with the old case. For me, this will raise an endless loop problem because the creATE statement was not updated in the TARGETDB so that it would match the case from the REFERENCEDB, leaving the FunkyDbObjs definition case-wise different, in the syscomments table. This will lead to the objects being detected as different by SQL Compare during the next comparison, even though they have just been synchronized! Of course, this problem will only arise when synchronizing case sensitive databases, using the 'treat items as case-sensitive' option. I only have this kind of databases so for me this problem is very real. I hope everything is clearer now. Thank you, Bogdan / comments

Hi Brian, Thank you for your help. I understand the fact that there is no option for partial code comparison using case sensitivity/insensitivity and I never expected this behaviour.Please, let me ...

0 votes

Indeed, but there should be an option for this behaviour because there are some technical advantages with issuing an ALTER statement vs. CREATE, such as the fact that it doesn't affect any dependent stored procedures or triggers. / comments

Indeed, but there should be an option for this behaviour because there are some technical advantages with issuing an ALTER statement vs. CREATE, such as the fact that it doesn't affect any dependen...

0 votes

I need case sensitivity and when this is activated, SQL Compare is malfunctioning. / comments

I need case sensitivity and when this is activated, SQL Compare is malfunctioning.

0 votes

How can we help you today?

Bogdan Iosif

Comments