Replication deployment model

How to package the correct set of necessary assemblies along with the client
to ensure that the software can function correctly while deploying
replication implementation along with software.
Is MS planning to provide a merge module or similar for the replication
featureset?
what is the recommended deployment model for stand-alone clients which are
replicating(Merge Replication) between a local and remote server where the
local doesn't include an install of the SQL management tools? (It will have
express.)
Abhi,
you can use RMO to create a pull subscription. To synchronize, you can also
use RMO or Windows Synchronization Manager or invoking the agent executable
files from the command prompt with a supplied set of parameters.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Replication and Reports

Hi!
I have transactional replication setup to a remote server. My
application is pointing to that server for reporting function.
Everytime I ran a report it locks the replication and replication
times out. In my reports I specified No Lock (not sure if this did
anything) but reporting still locking replication.
Any suggestions on how to implement reporting and replication so the
latter doesn't lock the former?
Thank you,
T.
In your reports, perhaps you have missed some nolock hints. It's easier to
set the transaction isolation level to read_uncommitted for the reporting
connection. Once that is done, start the distribution agent and if there is
still a problem, run profiler for the blocked process report (assuming sql
server 2005).
Also, if you are on sql server 2005, you might also want to investigate the
read_committed_snapshot option instead of nolock.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||On Feb 21, 10:13 am, "tolcis" <nytolly...@.gmail.com> wrote:
> Hi!
> I have transactional replication setup to a remote server. My
> application is pointing to that server for reporting function.
> Everytime I ran a report it locks the replication and replication
> times out. In my reports I specified No Lock (not sure if this did
> anything) but reporting still locking replication.
> Any suggestions on how to implement reporting and replication so the
> latter doesn't lock the former?
> Thank you,
> T.
Start by reviewing the indexes that are on your tables, and the
execution plans of the queries that your reports are running.
Reporting functions usually require a totally different indexing
strategy than transactional processing does. Proper indexes and
efficient queries will help minimize locking.

Replication and Reports

Hi!
I have transactional replication setup to a remote server. My
application is pointing to that server for reporting function.
Everytime I ran a report it locks the replication and replication
times out. In my reports I specified No Lock (not sure if this did
anything) but reporting still locking replication.
Any suggestions on how to implement reporting and replication so the
latter doesn't lock the former?
Thank you,
T.In your reports, perhaps you have missed some nolock hints. It's easier to
set the transaction isolation level to read_uncommitted for the reporting
connection. Once that is done, start the distribution agent and if there is
still a problem, run profiler for the blocked process report (assuming sql
server 2005).
Also, if you are on sql server 2005, you might also want to investigate the
read_committed_snapshot option instead of nolock.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com|||On Feb 21, 10:13 am, "tolcis" <nytolly...@.gmail.com> wrote:
> Hi!
> I have transactional replication setup to a remote server. My
> application is pointing to that server for reporting function.
> Everytime I ran a report it locks the replication and replication
> times out. In my reports I specified No Lock (not sure if this did
> anything) but reporting still locking replication.
> Any suggestions on how to implement reporting and replication so the
> latter doesn't lock the former?
> Thank you,
> T.
Start by reviewing the indexes that are on your tables, and the
execution plans of the queries that your reports are running.
Reporting functions usually require a totally different indexing
strategy than transactional processing does. Proper indexes and
efficient queries will help minimize locking.

Replication and Reports

Hi!
I have transactional replication setup to a remote server. My
application is pointing to that server for reporting function.
Everytime I ran a report it locks the replication and replication
times out. In my reports I specified No Lock (not sure if this did
anything) but reporting still locking replication.
Any suggestions on how to implement reporting and replication so the
latter doesn't lock the former?
Thank you,
T.In your reports, perhaps you have missed some nolock hints. It's easier to
set the transaction isolation level to read_uncommitted for the reporting
connection. Once that is done, start the distribution agent and if there is
still a problem, run profiler for the blocked process report (assuming sql
server 2005).
Also, if you are on sql server 2005, you might also want to investigate the
read_committed_snapshot option instead of nolock.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com|||On Feb 21, 10:13 am, "tolcis" <nytolly...@.gmail.com> wrote:
> Hi!
> I have transactional replication setup to a remote server. My
> application is pointing to that server for reporting function.
> Everytime I ran a report it locks the replication and replication
> times out. In my reports I specified No Lock (not sure if this did
> anything) but reporting still locking replication.
> Any suggestions on how to implement reporting and replication so the
> latter doesn't lock the former?
> Thank you,
> T.
Start by reviewing the indexes that are on your tables, and the
execution plans of the queries that your reports are running.
Reporting functions usually require a totally different indexing
strategy than transactional processing does. Proper indexes and
efficient queries will help minimize locking.

Replication

Can you please help. I am trying to do a merge replication and i get the following error:

Procedure or function sp_MSaddinitialarticle has too many arguments specified.
(Source: SUB_SERVER (Data source); Error number: 8144)
----------------------------------
The process could not deliver the snapshot to the Subscriber.
(Source: Merge Replication Provider (Agent); Error number: -2147201001)
----------------------------------This error is usually caused by a schema change that isn't propagated to one or more subscribers. Was the machine reporting this problem "out of circulation" during the last schema change?

-PatP|||Any network issues between the servers?
What is the default query timeout value set?

And also try to reduce the MergeHistory table rows.|||Pat what do you mean by schema change because i ended up creating a new table only with 2 fields and still get the same problem, can you please elaborate on schema change|||I haven't actually done this myself, but I've run into a situation where it cropped up. We eventually "deep sixed" the offending server and rebuilt a fresh copy.

Let's assume that you have 20 servers participating in merge replication to support a high transaction volume web-site. You periodically take some of them offline for maintenance. When five servers are down, you make a schema change. Four of them come back online later in the day, but one has more serious problems so it stays offline for another four days while you get parts.

When that "prodigal child" comes back online, it still won't know about the schema change. In a high transaction volume situation, you almost certainly don't have five days worth of replication saved up. Bingo, Houston, we have a problem here!

-PatP|||Thanks Pat, i managed to rebuild the server and is working.

Now my other question which i already posted in the forums reads:
Is there a way to replicate the table permissions from publisher to
subscriber? I noticed that when replication takes place, the permissions
that were set up on tables on the subscriber are wiped out.