Comments
Sort by recent activity
the two new columns were added after the last (old) column. i had to use "force column order".
however i had to split the sync into three steps:
1) had to sync only the table with the two added columns with "force column order"
2) i had to "modify" my existing UDF that queries every column of that table and press "execute" in management studio (without changing any character in the alter function script) - as long as i would not have done this: my UDF would not have returned the two new columns - even if it querys "*"
3) had to sync other UDFs that are calling the UDF from step two
the same problem:
please see http://forums.asp.net/t/1359702.aspx for additional info about it.
why do i have to manually call "alter function" first - without changing anything actually! - to get SQL Server to return the two new columns?
do you have any hints/answers to my questions on the asp.net forum?
thanks, toebens / comments
the two new columns were added after the last (old) column. i had to use "force column order".
however i had to split the sync into three steps:
1) had to sync only the table with the two added col...
Brian Donahue wrote:
...
Because the keys are dropped and recreated, there is a chance that the script will fail and rollback if the data migrated was inconsistent.
For this reason, the constraints disabled by SQL Data Compare are created WITH NOCHECK to ensure that the data migrated over remains as consistent as it had been in the source database. We have extensively evaluated this decision and for technical reasons it is very unlikely that this behavior will change.
It is ok that the sync script will disable the constraints to perform the actual inserts BUT it would be cool if it could re-create/re-store the constraints like they were before (exactly), so there would not be a need to set "ignore WITH NOCHECK" or to re-compare and sync with sql compare (not sql data compare) again / comments
Brian Donahue wrote:
...
Because the keys are dropped and recreated, there is a chance that the script will fail and rollback if the data migrated was inconsistent.
For this reason, the constrai...
the generated script for version 6.1 and 7.0 don't differ very much. they differ in the format of the datetime value:
Script created by SQL Data Compare version 7.0.0.512 from Red Gate Software Ltd at 22.09.2008 14:30:52
there i had to add manually:
SET LANGUAGE 'US_ENGLISH'
GO
....
-- Add 2 rows to [dbo].[Fiscal]
SET IDENTITY_INSERT [dbo].[Fiscal] ON
INSERT INTO [dbo].[Fiscal] ([FiscalID], [FiscalYear], [BaroVoteBeginDate], [BaroVoteEndDate]) VALUES (1, 2008, '2008-09-17 00:00:00.000', '2008-09-30 00:00:00.000')
INSERT INTO [dbo].[Fiscal] ([FiscalID], [FiscalYear], [BaroVoteBeginDate], [BaroVoteEndDate]) VALUES (2, 2009, '2009-07-15 00:00:00.000', '2009-07-15 00:00:00.000')
SET IDENTITY_INSERT [dbo].[Fiscal] OFF
Script created by SQL Data Compare version 6.1.1.6 from Red Gate Software Ltd at 22.09.2008 17:08:54
(here i don't have to set the language explicitly - manually)
-- Add 2 rows to [dbo].[Fiscal]
SET IDENTITY_INSERT [dbo].[Fiscal] ON
INSERT INTO [dbo].[Fiscal] ([FiscalID], [FiscalYear], [BaroVoteBeginDate], [BaroVoteEndDate]) VALUES (1, 2008, '20080917 00:00:00.000', '20080930 00:00:00.000')
INSERT INTO [dbo].[Fiscal] ([FiscalID], [FiscalYear], [BaroVoteBeginDate], [BaroVoteEndDate]) VALUES (2, 2009, '20090715 00:00:00.000', '20090715 00:00:00.000')
SET IDENTITY_INSERT [dbo].[Fiscal] OFF
please fix this error in the new version ASAP / comments
the generated script for version 6.1 and 7.0 don't differ very much. they differ in the format of the datetime value:
Script created by SQL Data Compare version 7.0.0.512 from Red Gate Software Ltd...
same problem here - hopefully there is a fix very soon
SET LANGUAGE 'US_ENGLISH' worked so far - (but now i get different errors - will post em in a new topic) / comments
same problem here - hopefully there is a fix very soon
SET LANGUAGE 'US_ENGLISH' worked so far - (but now i get different errors - will post em in a new topic)