Comments for SQL Slayer http://www.sqlslayer.com/wp Making SQL do what we want it to do. Wed, 28 Apr 2010 03:52:51 -0700 http://wordpress.org/?v=2.8.4 hourly 1 Comment on “RowGUID is neither a DataColumn nor a DataRelation for table summary. (System.Data)” by Lynton 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/comment-page-1/#comment-115 Lynton Wed, 28 Apr 2010 03:52:51 +0000 http://www.sqlslayer.com/wp/?p=187#comment-115 Jeff, I can confirm the same problem still exists in SQL Server 2008 SP1 and I have found NO other documentation regarding this issue. IMHO it is a bug not a limitation. If periods are not allowed then validate the name of the publication before allowing it to be saved! It won't allow merge publications if there is anything (ANYTHING) else wrong with your database but will allow the publication name to be saved to prevent resolving conflicts. Just ridiculous and has caused many hours of frustration! I had exactly the same error and caused by that blasted dot. In my case I found out about it at the end of a republisher pushing out filtered subscriptions and had to roll all the way back to the central publisher and start all over again, again... Another "dot-related" issue to be aware of for merge replication... For example, I have schema [A] and schema [B] both have tables called [Info]. I have filtered replication going on A.Info and wanted to use joins to enforce integrity on other filtered articles. So the example WHERE clause would be "WHERE A.Info.ID = B.Info.ID" Joins in filtered replications ONLY support 2 part naming conventions! This means the valid caluse has to be "WHERE Info.ID = Info.ID" The builder is automated so you can't alias anything and are stuck with it. My work around was to create a seperate filter for each table rather than using the Joins. Despite the setup issues with merge replication, once it is up and running it is great stuff. I still recommend creating back up jobs on all subscribers (ours are SQL Express 2008) and purchasing RedGate's SQL Toolbelt so data compares can be done in the case of failures or data loss. Jeff,

I can confirm the same problem still exists in SQL Server 2008 SP1 and I have found NO other documentation regarding this issue.

IMHO it is a bug not a limitation. If periods are not allowed then validate the name of the publication before allowing it to be saved! It won’t allow merge publications if there is anything (ANYTHING) else wrong with your database but will allow the publication name to be saved to prevent resolving conflicts. Just ridiculous and has caused many hours of frustration!

I had exactly the same error and caused by that blasted dot. In my case I found out about it at the end of a republisher pushing out filtered subscriptions and had to roll all the way back to the central publisher and start all over again, again…

Another “dot-related” issue to be aware of for merge replication…
For example, I have schema [A] and schema [B] both have tables called [Info].
I have filtered replication going on A.Info and wanted to use joins to enforce integrity on other filtered articles.

So the example WHERE clause would be “WHERE A.Info.ID = B.Info.ID”

Joins in filtered replications ONLY support 2 part naming conventions!
This means the valid caluse has to be “WHERE Info.ID = Info.ID”
The builder is automated so you can’t alias anything and are stuck with it.
My work around was to create a seperate filter for each table rather than using the Joins.

Despite the setup issues with merge replication, once it is up and running it is great stuff.
I still recommend creating back up jobs on all subscribers (ours are SQL Express 2008) and purchasing RedGate’s SQL Toolbelt so data compares can be done in the case of failures or data loss.

]]> Comment on GROUP BY CUBE example by tanvi http://www.sqlslayer.com/wp/2009/10/08/group-by-cube-example/comment-page-1/#comment-21 tanvi Fri, 30 Oct 2009 13:17:37 +0000 http://www.sqlslayer.com/wp/?p=114#comment-21 what is this al about what is this al about

]]> Comment on SQL SIG by TheSQLGeek http://www.sqlslayer.com/wp/2009/10/09/sql-sig/comment-page-1/#comment-10 TheSQLGeek Thu, 15 Oct 2009 00:35:59 +0000 http://www.sqlslayer.com/wp/?p=124#comment-10 Great site!!! I really enjoyed the presentation at the user group. Great site!!! I really enjoyed the presentation at the user group.

]]> Comment on Memory Leak in For Loop Container? by TheSQLGeek http://www.sqlslayer.com/wp/2009/10/13/memory-leak-in-for-loop-container/comment-page-1/#comment-9 TheSQLGeek Thu, 15 Oct 2009 00:34:13 +0000 http://www.sqlslayer.com/wp/?p=129#comment-9 I wanted to provide some quick information on the post above. SSIS uses buffers to manage the work that it handles in memory. You will not find these documented anywhere. You just have to know the person(s) who wrote that piece in SSIS. In SQL Server 2005 the buffers used inside of SSIS are as follows; Physical, Prime, Column View, Virtual. Now depending on how the task blocking or non blocking it utilizes the buffers in different ways. One thing that is important is the sheer size of the graph with SSIS. (Graph is the official term for the work/data flow orchestrations in SSIS) For performance and memory reasons to perf tune your package you need to size your graph to your buffer size that you setup in SSIS. Engine threads and work/transformation types will cause this number to move around a bit. You may also want to setup up some disk buffer on your laptop if you need to run the package on the 1 GB RAM system. By the sounds of the task we are holding multiple datasets in the prime buffers and the column view buffer as well. This will cause RAM swelling. As the data is kept in more than one buffer. I hope that my explain is sorta clear. The most important thing in SSIS is sizing your graph to your buffer. You can always pre stage your data in memory (included in SQL 2008 as Source and Destination Buffers) with a small amount of effort as well. I wanted to provide some quick information on the post above. SSIS uses buffers to manage the work that it handles in memory. You will not find these documented anywhere. You just have to know the person(s) who wrote that piece in SSIS. In SQL Server 2005 the buffers used inside of SSIS are as follows; Physical, Prime, Column View, Virtual. Now depending on how the task blocking or non blocking it utilizes the buffers in different ways. One thing that is important is the sheer size of the graph with SSIS. (Graph is the official term for the work/data flow orchestrations in SSIS) For performance and memory reasons to perf tune your package you need to size your graph to your buffer size that you setup in SSIS. Engine threads and work/transformation types will cause this number to move around a bit. You may also want to setup up some disk buffer on your laptop if you need to run the package on the 1 GB RAM system. By the sounds of the task we are holding multiple datasets in the prime buffers and the column view buffer as well. This will cause RAM swelling. As the data is kept in more than one buffer. I hope that my explain is sorta clear. The most important thing in SSIS is sizing your graph to your buffer. You can always pre stage your data in memory (included in SQL 2008 as Source and Destination Buffers) with a small amount of effort as well.

]]> Comment on Work-around for 2005 Maintenance Plan bug by mlakarj http://www.sqlslayer.com/wp/2009/10/06/work-around-for-2005-maintenance-plan-bug/comment-page-1/#comment-5 mlakarj Thu, 08 Oct 2009 14:33:56 +0000 http://www.sqlslayer.com/wp/?p=77#comment-5 We just use them for things like rolling backups on DEV and QA servers. For that, they do everything we need. We just use them for things like rolling backups on DEV and QA servers. For that, they do everything we need.

]]> Comment on Unable to restore backup from 2008 R2 to 2008 by Cliff Buckley http://www.sqlslayer.com/wp/2009/10/05/unable-to-restore-backup-from-2008-r2-to-2008/comment-page-1/#comment-3 Cliff Buckley Thu, 08 Oct 2009 00:40:59 +0000 http://www.sqlslayer.com/wp/?p=70#comment-3 Sometimes I just hate Microsoft. They make some things so easy then go slackjawed with other things. It's somewhat understandable with as many developers and pieces/parts they have working in SQL, but backups? Disaster recovery should be thier first focus, then feature enhancements and bug fixes. Sometimes I just hate Microsoft. They make some things so easy then go slackjawed with other things. It’s somewhat understandable with as many developers and pieces/parts they have working in SQL, but backups? Disaster recovery should be thier first focus, then feature enhancements and bug fixes.

]]> Comment on Work-around for 2005 Maintenance Plan bug by abean http://www.sqlslayer.com/wp/2009/10/06/work-around-for-2005-maintenance-plan-bug/comment-page-1/#comment-2 abean Wed, 07 Oct 2009 13:13:24 +0000 http://www.sqlslayer.com/wp/?p=77#comment-2 Jeff, I think you'll find some handy procedures in the admin database to handle these issues. Our maintenance procedures and the backup procedures will handle these issues for you. I have never been a fan of maintenance plans as they are very limited and in the end, only cause more frustration than they're worth. Jeff, I think you’ll find some handy procedures in the admin database to handle these issues. Our maintenance procedures and the backup procedures will handle these issues for you. I have never been a fan of maintenance plans as they are very limited and in the end, only cause more frustration than they’re worth.

]]>