InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSun, 19 May 2013 10:05:54 GMT20http://www.sqlservercentral.com/Forums/Topic737765-291-1.aspxUsers can connect to Server B but will not be able to select from whatever table the snapshot agent is currently working on since it will be locked by the bcp process the snapshot agent is running.[quote]but the client don't want to add the primary key for all tables[/quote]Wow :blink:...What a great opportunity for you to teach your client about why it's a good idea to put a PK on tables.While other people have mentioned log shipping and it sounds like it may be applicable to your situation, remember that log shipping covers the entire database. If you're replicating every table perhaps log shipping is a better solution. If you're replicating only a few tables log shipping may not be the best solution.Thu, 25 Jun 2009 09:16:18 GMTKendal Van Dykehttp://www.sqlservercentral.com/Forums/Topic737765-291-1.aspxThere are some options besides dropping a table and recreating it for snap shot replication (at least there is for SS 2000). You can "Delete all data in the existing table" instead of dropping the tables. This could reduce the time that tables are not available but if there is a table structure change, this could cause problems.I would recommend once a day, off hours snapshot replication or bite the bullet, add the primary key to all tables needed and use transaction replication. I'm sure that there are some articles on SSC that would give some useful arguements for setting up a relational database with primary keys.SteveWed, 24 Jun 2009 07:57:19 GMTsteve blockhttp://www.sqlservercentral.com/Forums/Topic737765-291-1.aspxI think a log shipping solution may be a little faster. Yes, the users will be knocked off when you restore the tran log (same as snapshot replication) but you're only restoring the tran log and not the entire DB.Wed, 24 Jun 2009 07:18:21 GMT2 Tim 3:16http://www.sqlservercentral.com/Forums/Topic737765-291-1.aspxSnapshot Replication might no be a good solution. Since it drops all objects and re-create them, I am sure the users will get disconnected somehow. Not only that, you may encounter some locking/blocking issues on the source server while the snapshot is generating.EdTue, 23 Jun 2009 15:14:52 GMTedmund chanhttp://www.sqlservercentral.com/Forums/Topic737765-291-1.aspxIs that I proposed first time - transactional replication - but the client don't want to add the primary key for all tables. Result: no transactional replication! and they want all that replicated, no just some tables for the purpose of reporting.Thanks,PaulaTue, 23 Jun 2009 07:53:26 GMTpaula_ancaIhttp://www.sqlservercentral.com/Forums/Topic737765-291-1.aspxWhy dont you consider Transactional replication. I think it suits your environment. Initially the snapshot is generated and gets reflected at the subscriber and transactions that happen at the publisher will get reflected automatically at the subscriber without any problem.ThanksChandra Mohan NFri, 19 Jun 2009 09:56:55 GMTChand00http://www.sqlservercentral.com/Forums/Topic737765-291-1.aspxThank you :) !sorry for my laconic ton, I am overloaded and it shows.Thu, 18 Jun 2009 11:40:03 GMTpaula_ancaIhttp://www.sqlservercentral.com/Forums/Topic737765-291-1.aspxUsers can fetch reports from server BThu, 18 Jun 2009 11:07:02 GMTPradyothana Shastryhttp://www.sqlservercentral.com/Forums/Topic737765-291-1.aspxSituation: Server A replicated on server B, snapshot replication on every 30 min, DB size 4Gb. Are users able to connect to server B while Snapshot/Distribution Agent running? Server B is set for reporting purpose and users are running the reports all time, even in the snapshot replication laps of time.Thu, 18 Jun 2009 10:42:16 GMTpaula_ancaI