Comments
Sort by recent activity
You are correct, the synchronization script does show the full where clause for the index in my example. However, the difference display and the comparison routine is where the problem lies.
First, create the table and filtered index in Database1 and do nothing in Database 2. Run your compare and you'll see the display will be incorrect (and not because of scrolling), however the sync script will be correct.
Next, create only the table in Database2 and run another compare. You'll find the same results--display is incorrect, sync script is correct.
Finally, create the index without the filter in Database2. Run a compare. You'll see that the comparison process fails at this point, as it will show those tables as identical. Therefore, a synchronization script will also be incorrect, as that table will be excluded. / comments
You are correct, the synchronization script does show the full where clause for the index in my example. However, the difference display and the comparison routine is where the problem lies.
First,...
Thanks for the link--I see (and have now tested) that computed columns are dropped/added in this version of Compare, and may have been available from version 6, for all I know! So that solves 80% of my issue. But I still question why persisted computed columns aren't treated the same way. Drop/Add works just as well for those, too.
Thanks for your reply.
Jason / comments
Thanks for the link--I see (and have now tested) that computed columns are dropped/added in this version of Compare, and may have been available from version 6, for all I know! So that solves 80% o...
It does work correctly if the parameter is bound to the schema collection in the definition, such as: CREATE PROC cms.pRecordPayment2
@PaymentXML xml(cms.xsdPayment)
AS
SELECT @PaymentXML
GO
although I still get the goofy [RG::XMLSC:::].[cms].[xsdPayment] thing. / comments
It does work correctly if the parameter is bound to the schema collection in the definition, such as:CREATE PROC cms.pRecordPayment2
@PaymentXML xml(cms.xsdPayment)
AS
SELECT @Paym...
And before anyone asks why I'm not simply coding my stored procedures correctly (as in #2), the unfortunate reality is that these procs are front-ended by ColdFusion Server, which throws up if we try to pass XML to the database as an actual XML parameter. Therefore, I must receive it as text and convert it to a real XML object. :x / comments
And before anyone asks why I'm not simply coding my stored procedures correctly (as in #2), the unfortunate reality is that these procs are front-ended by ColdFusion Server, which throws up if we t...
HI Brian,
Yes, let me clarify. It's not the tables, but the stored procedures. I haven't tested functions or views. For instance, I have a stored procedure that takes input from a webservice and validates against the XML Schema Collection as such: CREATE XML SCHEMA COLLECTION [cms].[xsdPayment]
AS N'<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">...
CREATE PROC cms.pRecordPayment
@PaymentXML nvarchar(max)
AS
SET NOCOUNT ON;
DECLARE @DocHandle int, @myXML xml;
EXEC sp_xml_preparedocument @DocHandle OUTPUT, @PaymentXML;
SET @myXML = CAST(@PaymentXML AS XML(cms.xsdPayment)) ;
...
This behavior has been the same on SQL Server 2005 (comp. 80 and 90) and on SQL Server 2008 (comp. 90 and 100). / comments
HI Brian,
Yes, let me clarify. It's not the tables, but the stored procedures. I haven't tested functions or views. For instance, I have a stored procedure that takes input from a webservice and va...