Showing posts with label fails. Show all posts
Showing posts with label fails. Show all posts

Monday, March 26, 2012

Merge Agent fails to connect to mdb

Hi all,
Here is a challenge - and I'm loosing ...
I'm trying to get a push subscription to work to an Access mdb file from
SQLServer.
I get the following message when running the Merge Agent:
'S:\network\share\access.mdb' is not a valid path. Make sure that the path
name is spelled correctly and that you are connected to the server on which
the file resides.
(Source: MS.Jet.4.0 (Agent); Error number: -1023)
I'm successfully using the subscription's Linked Server definition via QA.
So I conclude that the .mdb path is valid.
I've successfully test the push replication with the .mdb file as a local
file.
My guess is that it is a security context issue for the Merge Agent -
however I don't know how to correct it!!!
I've checked the Agent definition - and it is running with the owner set to
the local admin account.
Both my SQLServer Instance and Agent service use the same local
administrator account (not LocalSystem). This account has got access to the
share and can open the mdb file via Access).
Environment:
SQLServer PE V7.0 with SP3a
Windows 2003 Server with SP1
Hope that someone has been here, and got the t-shirt...
Peter
Is S a network drive? If so you have to access it as a UNC. Secondly, IIRC
everytime the agent runs it creates a new copy of the database,
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Peter" <Peter@.discussions.microsoft.com> wrote in message
news:D872C520-1D22-4397-8A55-7E0A02DA4D26@.microsoft.com...
> Hi all,
> Here is a challenge - and I'm loosing ...
> I'm trying to get a push subscription to work to an Access mdb file from
> SQLServer.
> I get the following message when running the Merge Agent:
> 'S:\network\share\access.mdb' is not a valid path. Make sure that the
> path
> name is spelled correctly and that you are connected to the server on
> which
> the file resides.
> (Source: MS.Jet.4.0 (Agent); Error number: -1023)
> I'm successfully using the subscription's Linked Server definition via QA.
> So I conclude that the .mdb path is valid.
> I've successfully test the push replication with the .mdb file as a local
> file.
> My guess is that it is a security context issue for the Merge Agent -
> however I don't know how to correct it!!!
> I've checked the Agent definition - and it is running with the owner set
> to
> the local admin account.
> Both my SQLServer Instance and Agent service use the same local
> administrator account (not LocalSystem). This account has got access to
> the
> share and can open the mdb file via Access).
> Environment:
> SQLServer PE V7.0 with SP3a
> Windows 2003 Server with SP1
> Hope that someone has been here, and got the t-shirt...
> --
> Peter
|||Hi Hilary,
Yes S is a mapped network drive.
I have created a new Linked Server def using the UNC reference to the mdb.
Again the linked server def works fine when used in Query Analyser to select
data from the mdb.
However, I again get the msg below in my Merge Agent when using the Linked
Server def in a push subscription:
'\\server\path1\path2\access.mdb' is not a valid path. Make sure that the
path name is spelled correctly and that you are connected to the server on
which the file resides.
(Source: MS.Jet.4.0 (Agent); Error number: -1023)
------
Any ideas?
Curious about your second comment about creating a new copy of the database
everytime the agent runs - I did not see this when running the agent against
my local test copy of the mdb.
Regards,
Peter
Peter
"Hilary Cotter" wrote:

> Is S a network drive? If so you have to access it as a UNC. Secondly, IIRC
> everytime the agent runs it creates a new copy of the database,
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Peter" <Peter@.discussions.microsoft.com> wrote in message
> news:D872C520-1D22-4397-8A55-7E0A02DA4D26@.microsoft.com...
>
>

Merge agent fails due to deadlock

Hi:
I met a problem this morning. the merge replication agen stopped, the
error message shows:
The process could not enumerate changes at the 'Publisher'.
(Source: Merge Replication Provider (Agent); Error number: -2147200999)
-----
Transaction (Process ID 79) was deadlocked on lock resources with
another process and has been chosen as the deadlock victim. Rerun the
transaction.
(Source: XXXXXX (Data source); Error number: 1205)
The process was successfully stopped.
(Source: Merge Replication Provider (Agent); Error number: -2147200999)
I never met this issue before, so please help
1) What may cause this issue?
2) How I could identify which process cause the deadlock issue?
3) Is there any way to log more information to identify what resource
is deadlock, and by who.
Thanks
Yong
Yong,
have a look at enabling traceflags 1204, 1205, 3605 to get more info. Don't
forget to turn off afterwards. Alternatively if you have sql server 2005,
the profiler shows the deadlock tree graphically.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql

Merge agent fails creating snapshot in FTP directory.

Hello all.
Me again. I'm finding some of these replication errors very hard to track
down. With your great guidance I'm working on replicating via the internet. I
think I know what has to be done now, but when configuring the publisher to
create ftp snapshots, the snapshot agent is throwing an error of:
The process could not create file
'D:\snapshots\ftp\DB_Test_DB_Test\20050411145407'.
Cannot create a file when that file already exists.
(Source: (OS); Error number: 183)
I have no idea why this is occuring. The directory is empty when I start,
that numbered directory is created by the snapshot agent fine. Why the heck
won't it continue and generate the snapshots inside the directory? The error
isn't making any sense at all.
Any help would be greatly appreciated.
Very strange. Can you check that you're just using the alternative snapshot
location only - this is recommended but shouldn't cause any problem. Also,
can you delete the directory and rerun the snapshot agent. Actually, it
might be due to an identically named article - I know this isn't possible,
but if you are using owner prefixes to distinguish objects it might be
possible. Perhaps you can enable logging and we'll find out the object name
involved (http://support.microsoft.com/?id=312292).
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul your a genius, I would of never thought of that being the problem. It
seems as if it was trying to generate snapshots in both locations, but
failed. I'm finding theres lots of tid bits about SQL 2000 replication that
you have to know because it doesn't all work as you expect sometimes.
Great that you guys are around though. I greatly appreciate your help
throughout. I did replication via handheld devices with msdn's help and this
technology can be awesome once you get a hang of it.
Now lets hook up my subscribers and hope all goes well!
Thanks again and take care.
"Paul Ibison" wrote:

> Very strange. Can you check that you're just using the alternative snapshot
> location only - this is recommended but shouldn't cause any problem. Also,
> can you delete the directory and rerun the snapshot agent. Actually, it
> might be due to an identically named article - I know this isn't possible,
> but if you are using owner prefixes to distinguish objects it might be
> possible. Perhaps you can enable logging and we'll find out the object name
> involved (http://support.microsoft.com/?id=312292).
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Hmm one question I do have. Now that the snapshots are generated, I don't
recall the subscriber configuration ever asking for a FTP login/password.
How does the FTP login info work? Do I have to setup the FTP login
information to match an SQL login?
"Synced" wrote:
[vbcol=seagreen]
> Paul your a genius, I would of never thought of that being the problem. It
> seems as if it was trying to generate snapshots in both locations, but
> failed. I'm finding theres lots of tid bits about SQL 2000 replication that
> you have to know because it doesn't all work as you expect sometimes.
> Great that you guys are around though. I greatly appreciate your help
> throughout. I did replication via handheld devices with msdn's help and this
> technology can be awesome once you get a hang of it.
> Now lets hook up my subscribers and hope all goes well!
> Thanks again and take care.
> "Paul Ibison" wrote:
|||AFAIR in SQL Server 7.0 the ftp login info was set up on the subscriber
side, but not so in SQL Server 2000. Here it is part of the publication
properties. If you have successfully synchronized, this is because the
anonymous FTP has been enabled.
Rgds,
Paul Ibison
|||Hmm looks like I have a dilemma. Some of my subscribers are going to be
behind a firewall. Is there a way to tell the subscription FTP client to use
PASSIVE mode?
I don't think microsoft would have left this out but I can't seem to find
any info.
Thanks again guys!
"Synced" wrote:
[vbcol=seagreen]
> Hmm one question I do have. Now that the snapshots are generated, I don't
> recall the subscriber configuration ever asking for a FTP login/password.
> How does the FTP login info work? Do I have to setup the FTP login
> information to match an SQL login?
> "Synced" wrote:
|||Synced,
what is PASSIVE mode?
If you can't open port 21 then there is another option. Create the snapshot,
get it to the subscriber, then subscribe and select to use an alternative
snapshot location - on the properties of the distribution agent.
Rgds,
Paul Ibison
"Synced" <Synced@.discussions.microsoft.com> wrote in message
news:93709910-3C8E-4148-8BFA-090FE78C219F@.microsoft.com...[vbcol=seagreen]
> Hmm looks like I have a dilemma. Some of my subscribers are going to be
> behind a firewall. Is there a way to tell the subscription FTP client to
> use
> PASSIVE mode?
> I don't think microsoft would have left this out but I can't seem to find
> any info.
> Thanks again guys!
> "Synced" wrote:
|||Hey Paul,
I'm not sure how familiar you are with the FTP protocol, but the FTP
protocol has 2 modes, active and passive. Active is very difficult for
systems behind a firewall because of the flawed design in the FTP protocol.
Although FTP was designed way before firewalls were required for security.
Basically FTP by default runs in active mode. I log into an FTP, when I do a
dir, or GET, my client chooses a random port to transfer data on, tells the
FTP server, the FTP server actually does the connecting to the client. So
port 21 is only really the "control" port, not the data transfer port.
In passive mode, its the other way around. Passive FTP is automatically used
in IE etc I believe because so many people are behind NAT's and firewalls.
Right now my subscriber is behind a firewall so allowing port 21 is not
solving this issue. If I ftp in a FTP client, in default mode (active) I
cannot do a dir, or get command, but if I enable passive, everything works
fine.
My question is. Is there a way to enable passive mode for whatever
mechanism replication uses for a FTP client?
Does replication agent use the command like ftp command? If so the command
line ftp.exe doesn't support passive mode. If it does use ftp.exe, can I
swap ftp.exe with a 3rd party one that supports passive mode.
I really hope we can find a solution for this. Basically when I run my
subscription, it just says connecting to server... and sits there. But when I
FTP in a ftp client with the same info it logs in fine. just can't transfer
any data unless you enable passive mode.
I really hope I'm not totally stuck on this. I can't see this being not
possible since many many servers are behind firewalls these days.
Thanks a ton Paul,
Take care.
"Paul Ibison" wrote:

> Synced,
> what is PASSIVE mode?
> If you can't open port 21 then there is another option. Create the snapshot,
> get it to the subscriber, then subscribe and select to use an alternative
> snapshot location - on the properties of the distribution agent.
> Rgds,
> Paul Ibison
>
> "Synced" <Synced@.discussions.microsoft.com> wrote in message
> news:93709910-3C8E-4148-8BFA-090FE78C219F@.microsoft.com...
>
>
|||Synced,
I'm not going to be able to help much more as this is way, way beyond my
knowledge/experience of FTP. In my case I go through 2 firewalls and I just
asked the network guys to open up port 21 on both of them which worked fine.
Perhaps someone else can contribute here for us....
Rgds,
Paul
"Synced" <Synced@.discussions.microsoft.com> wrote in message
news:732B58F3-73D9-4D38-AC7D-68E527AC2274@.microsoft.com...[vbcol=seagreen]
> Hey Paul,
> I'm not sure how familiar you are with the FTP protocol, but the FTP
> protocol has 2 modes, active and passive. Active is very difficult for
> systems behind a firewall because of the flawed design in the FTP
> protocol.
> Although FTP was designed way before firewalls were required for security.
> Basically FTP by default runs in active mode. I log into an FTP, when I do
> a
> dir, or GET, my client chooses a random port to transfer data on, tells
> the
> FTP server, the FTP server actually does the connecting to the client. So
> port 21 is only really the "control" port, not the data transfer port.
> In passive mode, its the other way around. Passive FTP is automatically
> used
> in IE etc I believe because so many people are behind NAT's and firewalls.
> Right now my subscriber is behind a firewall so allowing port 21 is not
> solving this issue. If I ftp in a FTP client, in default mode (active) I
> cannot do a dir, or get command, but if I enable passive, everything works
> fine.
> My question is. Is there a way to enable passive mode for whatever
> mechanism replication uses for a FTP client?
> Does replication agent use the command like ftp command? If so the command
> line ftp.exe doesn't support passive mode. If it does use ftp.exe, can I
> swap ftp.exe with a 3rd party one that supports passive mode.
> I really hope we can find a solution for this. Basically when I run my
> subscription, it just says connecting to server... and sits there. But
> when I
> FTP in a ftp client with the same info it logs in fine. just can't
> transfer
> any data unless you enable passive mode.
> I really hope I'm not totally stuck on this. I can't see this being not
> possible since many many servers are behind firewalls these days.
> Thanks a ton Paul,
> Take care.
> "Paul Ibison" wrote:

Merge Agent fails - "Invalid character value for cast specificatio

Hi
From http://support.microsoft.com/kb/867880 it seems to have been fixed in
release 952. If you call PSS they should be able to give you the approriate
patch.
John
"Luke Ward" wrote:

> Hi Guys
> This above error is suppose to be fixed in SP4 for SQL Server 2000, howeve
r,
> SP4 is not available yet!
> Does anyone know of a HOT FIX or work around?
> Many Thanks
> Luke
>
>Thanks, I will give them a call
btw - both my servers are on SP3a
Cheers
Luke
"John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
news:EDF66E5C-3BEE-4F80-A24B-49868D66D251@.microsoft.com...
> Hi
> From http://support.microsoft.com/kb/867880 it seems to have been fixed in
> release 952. If you call PSS they should be able to give you the
> approriate
> patch.
> John
>
> "Luke Ward" wrote:
>|||Hi Guys
MS Tech gave me a fix, which did not fix it, I have now applied SP4, and
still get the same error :-(
I am going to see if I can attach logging to the publication.
What else can I do? any advise appreciated.
Luke
"Luke Ward" <lukeward@.campbelluk.com> wrote in message
news:OkrgViKUFHA.2940@.TK2MSFTNGP10.phx.gbl...
> Thanks, I will give them a call
> btw - both my servers are on SP3a
> Cheers
> Luke
> "John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
> news:EDF66E5C-3BEE-4F80-A24B-49868D66D251@.microsoft.com...
>