A few random extra points: there are some issues with snapshots for reporting purposes - you can't back them up and you can't use FTI for your reporting. Conversely, FTI is supported out of the box for replication in SQL 2005. Also, concurrency issues are no longer a problem with the new isolation levels in SQL 2005.

Paul Ibison

Great article.  We are currently using a home grown Log Shipping process to copy logs from one location to 4 other locations with compression/decompression.  We also use the standby databases for user reporting and for programmers to research data problems.   The problem with reporting, as the article points out, is it kicks users out during log restoration; thus, we increase the restoration interval to every 2 hours.  What we are looking for is a combination of Log Shipping for warm standby and Replication for reporting.  So far, all I read is this is possible but tricky to setup.  I would love to see a detailed step by step instruction for this solution.  I am sure other people have similar needs.

Ryan,

If you're refering to SQL 2000, have you ever tried using sp_repladdcolumn?

Mark

As someone else noted the article was a bit old!! Replication is always difficult for GUI users but if you script then making changes to objects is a doddle. I'm not sure your article really mentioned the issues you get with making changes to a database which is replicated, e.g. in prod systems with controlled software releases you'll find index changes and such can be problematic. I've log shipped since 6.0 and it's a cool way to provide recovery, I've found generally 5 mins is about the minimum log ship, especially if you have many databases on a server - which is of course the problem with all such solutions - ideal for one of two databases but when you have 20 servers and a couple of hundred databases that pipe can get mightly narrow and the distance to your DR site can increase latency.

That said sql 2005 has some really cool slants you can apply so a follow up for 2005 might be good.