Replication problem.. Please help..

Hi,
I have set up replication successfully. Data from Publisher can be
replicated to Subscriber. I can check the data directly from Enterprise
Manager.
Before replication, the application calling the database work perfectly.
HOWEVER, after replication the application cannot operate with the
replicated tables while un-changed table still works fine.
Can anyone tell me what replication has done to the table and how to avoid
it?
Thanks so much!!
Andrew,
what type of replication are you using? It sound's like it's the presence of
new (GUID) columns and/or triggers that has caused issues. If it is the GUID
columns (merge and updating subscribers) then the app should use named
column lists and in this case it'll be invisible to the App. If you have
triggers that modify the base table then this can be an issue - I'll wait
for more info before going down that route.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul,
Thanks for your answer..
After checking, I found the following:
1. access right of the replicated tables are all missing;
2. all default values are missing; and
3. identity column is no longer identity column. it is just a normal column.
Do you know how to fix it?
Many Thanks.. :>
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23YlHLGPSGHA.524@.TK2MSFTNGP10.phx.gbl...
> Andrew,
> what type of replication are you using? It sound's like it's the presence
> of new (GUID) columns and/or triggers that has caused issues. If it is the
> GUID columns (merge and updating subscribers) then the app should use
> named column lists and in this case it'll be invisible to the App. If you
> have triggers that modify the base table then this can be an issue - I'll
> wait for more info before going down that route.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Andrew,
I assumed you were talking about the publisher. If it's the subscriber, you
need to open the article properties dialog screen (elipsis button) and on
the snapshot tab click the first 3 checkboxes. To get the permissions,
you'll need to add a post-snapshot script. For the identity column to remain
identity, I'd ask why? You must have set up a non-offline subscriber in
which case the identity attribute will never get used.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul,
Thanks for your help.
Just found that some tables have more than 255 column and cannot pass the
vertical replication when setting the publisher. If skip those too-large
table, it works well after running the script for granting permissions.
Seems the problems is about to be solved..
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uvPd6QaSGHA.5468@.TK2MSFTNGP14.phx.gbl...
> Andrew,
> I assumed you were talking about the publisher. If it's the subscriber,
> you need to open the article properties dialog screen (elipsis button) and
> on the snapshot tab click the first 3 checkboxes. To get the permissions,
> you'll need to add a post-snapshot script. For the identity column to
> remain identity, I'd ask why? You must have set up a non-offline
> subscriber in which case the identity attribute will never get used.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>

Replication problem - system cannot find the specified path

Hi,

I'm trying to set up transactional replication from one server to another (I've done this successfully a few times). I've set up the publications and pushed a subscription to the subscriber. But as soon as the snapshot agent starts, I get the following error

system cannot find the specified path

The path for the snapshot is valid, and I'm using a domain account which has acces to this folder to run the SQL Server Agent on both boxes.

Could anyone tell me where I'm going wrong?

IanFixed it!

For some reason, the path for certain executables used in replication is stored in the regisry in DOS format, so SQL Server was looking in microso~2 instead of microso~4. I changed this in the registry and everything was fine!sql

Replication over different computers

Dear All,
I can successfully create merge replication on the same
computer with two database instances. However, it didn't
success if I replicate over two computers.
I use push subscription and the subscriber seems
nothing to set (set the replication on the publisher).
Therefore, how can I control the access rights or else to
replicate to another computer?
Patrick
Patrick,
the sql server agnt's login must be in the db_owner role on the subscriber
database, db_owner in the distribution database and db_owner of the
publishing database and have the correct rights to the snapshot share.
What is the error when you run the merge agent?
Regards,
Paul Ibison
|||Is there any step-by-step guide to setup replication over
different computers

>--Original Message--
>Patrick,
>the sql server agnt's login must be in the db_owner role
on the subscriber
>database, db_owner in the distribution database and
db_owner of the
>publishing database and have the correct rights to the
snapshot share.
>What is the error when you run the merge agent?
>Regards,
>Paul Ibison
>
>.
>
|||Patrick,
BOL has all the details but not as a setup guide.
These links have step-by-step graphical setups:
http://www.mssqlcity.com/Articles/Re...MR/SetupMR.htm
http://www.sqlservercentral.com/arti...?categoryid=26
HTH,
Paul Ibison

Replication looking for errant sysserver links

We have replication successfully running but when I tried to set up a new test instance on completely different servers (Server A to Server B, say) the push agent to create the susbcription on Server B complains

'Could not find server 'Server C' in sysservers. Execute sp_addlinkedserver. . . .'

Server C was never configured as a subscriber for the publication in the first place. What's more, Server C is actually a working linked server and definitely is in sysservers for Server A.

I originally tried this on yet another server pair and got a similar message referencing a server name that no longer exists. I stopped messing with that one, figuring it was some historical naming issue I didn't want to mess with. But now I'm stumped and intrigued. Can anyone help?

Did you deploy your subscriber through a script? Perhaps you forgot to edit the script for the new topology.|||Unfortunately, no. I just used the Wizards, and specified everything. Bit bewildering.|||Do "select * from sysservers" to see if you have any rogue entries in there. You can remove the incorrect ones via sp_dropserver.|||

The supposedly unlinked server is definitely linked, and shows up correctly in the sysserver collection, which also looks fine.

It's wierd, but it's only a test instance I was trying to set up, Our live replication is working fine and we didn't really need the test this time.

I think these servers went through name changes. It probably had the server linked under its old name. Just a guess, but we had a lot of problems changing server names when our corporation was absorbed into a larger IT force and we had to follow a new naming convention. Replication broke, of course, and I recall we needed to clean out various tables before we could reimplement. So I'm guessing it's something along those lines.

Replication Logreader query

We had replication set up and working successfully for 2+ years between an intranet server and a webserver (offsite).

The web server was moved and the replication went out of sync. :mad:

Now when we try the replication it is trying to start from scratch and as you can imagine there is quite a lot of data after two years!

I have scheduled the logreader to run but after 8 hours it is still running is there any way to find out how long it should take?

We have removed any unnecessary data to try to help speed up the process.

Help appreciatedYou probably need the snapshot agent instead of the logreader agent. It takes the starting "snapshot" of the database to send to the subscriber, to restart replication.

-PatP|||We ran the snaphot first thing this morning - job outcome was successful.

Getting this message when we look at the snapshot step details for the run agent step:

"A snapshot was not generated because no subscriptions needed initialization. The step succeeded."

Any ideas on how to find out how long the logreader will take?|||Did you reinitialize the publications? That will flag the publication for a new snapshot. Just FYI, you probably want to script the indicies and the permissions on the subscriber, since the replicated tables will be destroyed and recreated as part of the process.

-PatP|||We have reinitialised the publications.

Thanks for the tip on indexes etc.

Any tips on finding out how long to complete the logreader and then distribution tasks? :confused:|||The logreader is eternal, if replication is going on, the logreader is running. The snapshot agent usually doesn't run too long, it simply copies the data from the published tables into flat files, but its performance is VERY dependant on your hardware (fast hardware/short runtime, slow hardware/well, you know that drill).

The distribution task depends on way too much stuff for me to take a guess at its performance... The network connection, the subscriber performance, the distributors disk, and about a half a gazillion other factors come into play.

Once the tasks start running, you can sometimes get better ideas about the performance, but knowing nothing about your configuration I can't even hazard a guess!

-PatP|||Pat

Distribution is executing - looks like it will be a long night :)

Thanks for your help - it is greatly appreciated

Cheers|||If you wander down to the distribution agents in your replication monitor (on the distributor), you can at least watch the "paint dry" via the status messages. It ain't much, but it is better than nothing!

-PatP