As I mentioned in my previous post, i would provide details of the data loss scenarios in Merge Replication topologies with SQL Server 2005. The details were published in this addendum to the original DevX article:
the article is basically two repros to illustrate the data loss when the partition groups are not use in the publication. The workaround is not published and the definite solution should be available on SQL SErver 2005 SP3 or the upcoming cumulative update in February 2008.
Today I came across a blog post regarding SQL Server bugs and how to provide the information to tech support or to the Connects program.
Please read this blog post if you are posting/investigating bugs. The more information you provide, the faster the bug might be scheduled for a fix:
What is interesting on that blog post is one of the comments from a MS employee “anna”:
I know there is no excuse to use fault language or be rude to have your bug scheduled first, however, there is also no excuse to have data loss due to insufficient testing or a newly introduced bug.
I can only speak for myself, but in our case the merge topology had worked fault free for over a year before we upgraded to the 2005 version.
We are humans and we err, but we are also accountable for our code and our testing procedures. It’s not a matter of taking pride on pointing out a fault. I would rather not have had the data loss issue at all and the overtime and stress that happened after in order to recover the data and avoid future losses.
Why taking so much pride in the work we do or the code we write? Maybe it’s better to ask why not?