SQL Slayer » SQL SERVER 2005 http://www.sqlslayer.com/wp Making SQL do what we want it to do. Wed, 18 Aug 2010 14:11:45 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 “RowGUID is neither a DataColumn nor a DataRelation for table summary. (System.Data)” http://www.sqlslayer.com/wp/2010/01/08/%e2%80%9crowguid-is-neither-a-datacolumn-nor-a-datarelation-for-table-summary-system-data%e2%80%9d/ http://www.sqlslayer.com/wp/2010/01/08/%e2%80%9crowguid-is-neither-a-datacolumn-nor-a-datarelation-for-table-summary-system-data%e2%80%9d/#comments Fri, 08 Jan 2010 15:41:12 +0000 mlakarj http://www.sqlslayer.com/wp/?p=187 We had merge replication in SQL Server 2005 set up that was working fine, except when trying to view conflicts, the Conflict Viewer would give this error: “RowGUID is neither a DataColumn nor a DataRelation for table summary. (System.Data)”.

The source of this it turns out was actually a period in the Publication name, as we [...]]]> We had merge replication in SQL Server 2005 set up that was working fine, except when trying to view conflicts, the Conflict Viewer would give this error: “RowGUID is neither a DataColumn nor a DataRelation for table summary. (System.Data)”.

The source of this it turns out was actually a period in the Publication name, as we had a “6.1” as part of the name. Other special characters would probably also cause trouble.

The only way to fix this was to drop the replication, resolve known conflicts manually with a data compare, recreate the replication, and reinitialize. After that, we could use the Conflict Viewer to resolve conflicts successfully.

This was a frustrating issue since the replication was allowed to be created with the period and worked completely fine, only the Conflict Viewer experienced trouble and it gave an error that did not accurately describe the issue.

The moral of the story is: don’t create a publication with a period in the name.

]]> http://www.sqlslayer.com/wp/2010/01/08/%e2%80%9crowguid-is-neither-a-datacolumn-nor-a-datarelation-for-table-summary-system-data%e2%80%9d/feed/ 1 Work-around for 2005 Maintenance Plan bug http://www.sqlslayer.com/wp/2009/10/06/work-around-for-2005-maintenance-plan-bug/ http://www.sqlslayer.com/wp/2009/10/06/work-around-for-2005-maintenance-plan-bug/#comments Tue, 06 Oct 2009 19:47:28 +0000 mlakarj http://www.sqlslayer.com/wp/?p=77 In working with SQL 2005 Maintenance Plan backup cleanup tasks, a frustrating bug was found.  It seems that when the ability to select “hours” as a time criterion was added in SP2, the door was opened for misinterpretation of time units.  For example, you can, in your local Management Studio, set the Plan to delete [...]]]> In working with SQL 2005 Maintenance Plan backup cleanup tasks, a frustrating bug was found.  It seems that when the ability to select “hours” as a time criterion was added in SP2, the door was opened for misinterpretation of time units.  For example, you can, in your local Management Studio, set the Plan to delete files greater that 4 days old, and when run on the server the Plan will delete files only greater than 4 WEEKS old.  This was the full mapping I found:

 SET                  ACTUAL
Hours   ->         Days
Days    ->         Weeks
Weeks  ->         Months
Months ->         Years
Years    ->         Years

I don’t know yet if this is fixed in 2008.  For 2005 at least, I suggest refraining from using the built-in “Maintenance Cleanup Tasks” in Maintenance Plans, and instead use a T-SQL Statement task with the snippet below.  This will truly delete greater than 4 days.  Set your time criteria however you like.

 

DECLARE @DateOlderThan datetime
SET @DateOlderThan = DATEADD(day,-4,GETDATE())

EXEC master.dbo.xp_delete_file
0 -- delete files
,N'H:\SQLBackup\INST3' --full path to the main directory
,N'bak'-- file extension
,@DateOlderThan-- delete files created before this timestamp
,1-- Including first-level sub

]]> http://www.sqlslayer.com/wp/2009/10/06/work-around-for-2005-maintenance-plan-bug/feed/ 2