I have an access front end and a SQL 2000 backend. In the backend I changed a ntext field to a text field using a script and it then placed the field at the end of the field list. when I try to make a change to a record on the front end I get an error that another user has edited the record and must re-edit it. I can then make a change to the record. If I do a refresh I then get the error again. I then moved the text field back into it's original position and the error went away. Can anyone explain this?Hi Doug:
I think if it is possible, please show use your error ID, then we can
get more information about the error.
Best Wishes
Wei Ci Zhousql
Showing posts with label script. Show all posts
Showing posts with label script. Show all posts
Tuesday, March 20, 2012
Another user has edited the record
I have an access front end and a SQL 2000 backend. In the backend I changed
a ntext field to a text field using a script and it then placed the field at
the end of the field list. when I try to make a change to a record on the f
ront end I get an error tha
t another user has edited the record and must re-edit it. I can then make a
change to the record. If I do a refresh I then get the error again. I then m
oved the text field back into it's original position and the error went away
. Can anyone explain this?Hi Doug:
I think if it is possible, please show use your error ID, then we can
get more information about the error.
Best Wishes
Wei Ci Zhou
a ntext field to a text field using a script and it then placed the field at
the end of the field list. when I try to make a change to a record on the f
ront end I get an error tha
t another user has edited the record and must re-edit it. I can then make a
change to the record. If I do a refresh I then get the error again. I then m
oved the text field back into it's original position and the error went away
. Can anyone explain this?Hi Doug:
I think if it is possible, please show use your error ID, then we can
get more information about the error.
Best Wishes
Wei Ci Zhou
Monday, March 19, 2012
Another SQL script question.
Hey all,
There is probably some server side property or method you can call that will tell you who the ASPNET user is running as (e.g., domain\ASPNET) which would allow you to use the other syntax to create a trusted connection.
How do i make sure that the local machine aspnet user account has privilages after installing my sql script on a local machine. ( this script gets run during my vb.net setup project. )
i was thinking about adding the user to the sql script its self. but i am unsure how to do this.
if anyone could help i would be greatly appreciative.
TIA
-Chris-Check out this link.
The link is for MSDE but applies to Sql Server too. It shows the syntax for adding new users to a database server and granting them access to specific databases.|||Thanks for you reply.
the syntax for adding a user assumes you know the full nt user account info. correct?
domain\user account.
what i would like to do is add the local machine\aspnet account. without knowing what the name of the local machine is.
if you have suggestion, please let me know.
TIA
Chris.|||I've gotten around that problem by using Sql Server authentication instead of a trusted connection.
-- Create Sql authentication login for 'SomeName'
EXEC sp_addlogin @.loginame='SomeName',@.passwd='SomePassword',@.defdb=N'SomeDefaultDb'
-- and making sure you are executing from 'SomeDatabase' grant access to 'SomeName' to the database 'SomeDatabase'
EXEC sp_grantdbaccess 'SomeName'
There is probably some server side property or method you can call that will tell you who the ASPNET user is running as (e.g., domain\ASPNET) which would allow you to use the other syntax to create a trusted connection.
Friday, February 24, 2012
Annon Merge over VPN: WSM Insanity
I have my replication "working", though I would like to script as much
of the client installation as possible, and running into mega
headaches.
Here's the setup:
Client - MSDE
connects to Publisher/Distributor via VPN
annonymous pull subscription
I can install my MSDE, create the db, logins, etc.
1) Through EM, I can create the subscription through wizard. (selecting
"Available to Synch Manager", "Start immediately"). It works.
Syncronization Manager (type in passwords) synch works.
2) I script the subscription created in 1). Delete subscription and run
script with osql (doesn't run Merge Agent job automatically. Why not? I
even put in an extra line: EXEC sp_start_job @.job_name =
'MERGE_AGENT_JOBNAME'). Go back to EM, right click on subsrciption -
Start Synchronizing. It works. WSM (type in passwords) synch works.
3). Delete subcription and recreate with same script as above. Go
straight to WSM. The subscription is in the list. Synch (type in
passwords). DOES NOT WORK!!! I get the error "the schema script <blah
blah blah> could not be propagated to the subscriber."
Why should I have to run the subscription once through EM before it
will work with WSM? I guess it has something to do with that Merge
Agent job and it needs to be fired off first?
Obviously EM will not be distributed to my end users in far off lands.
I want them to be able to run a script and then synch through WSM. What
is the best way to achieve this?
Much Thanks
answers in line.
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
<richerwin@.ubs-europe.org> wrote in message
news:1109180376.620053.87490@.o13g2000cwo.googlegro ups.com...
> I have my replication "working", though I would like to script as much
> of the client installation as possible, and running into mega
> headaches.
> Here's the setup:
> Client - MSDE
> connects to Publisher/Distributor via VPN
> annonymous pull subscription
> I can install my MSDE, create the db, logins, etc.
> 1) Through EM, I can create the subscription through wizard. (selecting
> "Available to Synch Manager", "Start immediately"). It works.
> Syncronization Manager (type in passwords) synch works.
I take it you are using SQL Authentication in WSM. If so your user will have
to enter the password each time WSM runs. You might want to use intergrated
authentication and enter the user account in the pal on the publisher.
> 2) I script the subscription created in 1). Delete subscription and run
> script with osql (doesn't run Merge Agent job automatically. Why not? I
> even put in an extra line: EXEC sp_start_job @.job_name =
> 'MERGE_AGENT_JOBNAME'). Go back to EM, right click on subsrciption -
> Start Synchronizing. It works. WSM (type in passwords) synch works.
The merge agent doesn't start automatically because you have defined it to
start on demand.
> 3). Delete subcription and recreate with same script as above. Go
> straight to WSM. The subscription is in the list. Synch (type in
> passwords). DOES NOT WORK!!! I get the error "the schema script <blah
> blah blah> could not be propagated to the subscriber."
This means that the subscriber does not have rights to read the snapshot
share. You will have to craft a new snapshot share which does not use the
administrative share (ie \\servername\c$\Program Files\Microsoft SQL
Server\MSSQL\ReplData\UNC). Make sure this new snapshot share has read
permission for the accounts or a group which the merge users are in, and
that this group or user has rights to read the underlying files and folders.
> Why should I have to run the subscription once through EM before it
> will work with WSM? I guess it has something to do with that Merge
> Agent job and it needs to be fired off first?
This does sound odd. Perhaps it is a rights issue.
> Obviously EM will not be distributed to my end users in far off lands.
> I want them to be able to run a script and then synch through WSM. What
> is the best way to achieve this?
> Much Thanks
>
|||
> This does sound odd. Perhaps it is a rights issue.
I create my subscription. Local machine is RICH-VAIO,
Publisher/Distributor is WSCLAN08; database is TMS. At both ends, the
SQL Server is the default instance.
1) I run the following Win2000 DOS BATCH command:
"C:\Program Files\Microsoft SQL Server\80\COM\replmerg.exe" -Publisher
[WSCLAN08] -PublisherDB [TMS] -Publication [pubUser100] -PublisherLogin
[tmsuser] -PublisherPassword [tmsuser] -Distributor [WSCLAN08]
-DistributorLogin [tmsuser] -DistributorPassword [tmsuser] -Subscriber
[RICH-VAIO] -SubscriberDB [TMS] -SubscriptionType 2
-SubscriberSecurityMode 0 -SubscriberLogin [tmsuser]
-SubscriberPassword []
and get the following log:
Microsoft SQL Server Merge Agent 8.00.760
Copyright (c) 2000 Microsoft Corporation
Connecting to Subscriber 'RICH-VAIO'
Connecting to Distributor 'WSCLAN08'
Initializing
Connecting to Publisher 'WSCLAN08'
Retrieving publication information
Retrieving subscription information
The subscription has been marked for reinitialization. Reinitialization
will occur the next time you synchronize this subscription.
The schema script
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
could not be propagated to the subscriber.
Category:NULL
Source: Merge Replication Provider
Number: -2147201001
Message: The schema script
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
could not be propagated to the subscriber.
Category:AGENT
Source: RICH-VAIO
Number: 0
Message: The process could not read file
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
due to OS error 1326.
Category:OS
Source:
Number: 1326
Message: Logon failure: unknown user name or bad password.
2) Immediately, I go to EM, right click on my subscription, and select
Start Synchronizing. The last entry in the log history is:
The job succeeded. The Job was invoked by User tmsuser. The last step
to run was step 1 (Run agent.).
3) Immediately, I run the same batch file as above. I get the following
log:
Microsoft SQL Server Merge Agent 8.00.760
Copyright (c) 2000 Microsoft Corporation
Connecting to Subscriber 'RICH-VAIO'
Connecting to Distributor 'WSCLAN08'
Initializing
Connecting to Publisher 'WSCLAN08'
Retrieving publication information
Retrieving subscription information
The merge process is cleaning up meta data in database 'TMS'.
The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
The merge process is cleaning up meta data in database 'TMS'.
The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
Uploading data changes to the Publisher
No data needed to be merged.
Downloading data changes to the Subscriber
4) Successive changes to the data at the subscriber are successfully
uploaded as in 3).
WHAT THE FREAK IS GOING ON WITH Merge Agent?
Please, please, please help. My kindom for a solution.
It must be noted I am not logged into Win2000 as tmsuser, though
tmsuser is a domain user under which SQLSERVER AGENT runs at the
subscriber, and tmsuser has full rights on the snapshot share at the
Publisher (as evident by the successful replications above).
|||just a wild thought here - why are you running the merge binary from the
command line?
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
<richerwin@.ubs-europe.org> wrote in message
news:1109221256.951320.175930@.f14g2000cwb.googlegr oups.com...
>
> I create my subscription. Local machine is RICH-VAIO,
> Publisher/Distributor is WSCLAN08; database is TMS. At both ends, the
> SQL Server is the default instance.
>
> 1) I run the following Win2000 DOS BATCH command:
> "C:\Program Files\Microsoft SQL Server\80\COM\replmerg.exe" -Publisher
> [WSCLAN08] -PublisherDB [TMS] -Publication [pubUser100] -PublisherLogin
> [tmsuser] -PublisherPassword [tmsuser] -Distributor [WSCLAN08]
> -DistributorLogin [tmsuser] -DistributorPassword [tmsuser] -Subscriber
> [RICH-VAIO] -SubscriberDB [TMS] -SubscriptionType 2
> -SubscriberSecurityMode 0 -SubscriberLogin [tmsuser]
> -SubscriberPassword []
> and get the following log:
> Microsoft SQL Server Merge Agent 8.00.760
> Copyright (c) 2000 Microsoft Corporation
> Connecting to Subscriber 'RICH-VAIO'
> Connecting to Distributor 'WSCLAN08'
> Initializing
> Connecting to Publisher 'WSCLAN08'
> Retrieving publication information
> Retrieving subscription information
> The subscription has been marked for reinitialization. Reinitialization
> will occur the next time you synchronize this subscription.
> The schema script
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> could not be propagated to the subscriber.
> Category:NULL
> Source: Merge Replication Provider
> Number: -2147201001
> Message: The schema script
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> could not be propagated to the subscriber.
> Category:AGENT
> Source: RICH-VAIO
> Number: 0
> Message: The process could not read file
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> due to OS error 1326.
> Category:OS
> Source:
> Number: 1326
> Message: Logon failure: unknown user name or bad password.
> 2) Immediately, I go to EM, right click on my subscription, and select
> Start Synchronizing. The last entry in the log history is:
> The job succeeded. The Job was invoked by User tmsuser. The last step
> to run was step 1 (Run agent.).
> 3) Immediately, I run the same batch file as above. I get the following
> log:
> Microsoft SQL Server Merge Agent 8.00.760
> Copyright (c) 2000 Microsoft Corporation
> Connecting to Subscriber 'RICH-VAIO'
> Connecting to Distributor 'WSCLAN08'
> Initializing
> Connecting to Publisher 'WSCLAN08'
> Retrieving publication information
> Retrieving subscription information
> The merge process is cleaning up meta data in database 'TMS'.
> The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
> in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
> The merge process is cleaning up meta data in database 'TMS'.
> The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
> in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
> Uploading data changes to the Publisher
> No data needed to be merged.
> Downloading data changes to the Subscriber
> 4) Successive changes to the data at the subscriber are successfully
> uploaded as in 3).
>
> WHAT THE FREAK IS GOING ON WITH Merge Agent?
> Please, please, please help. My kindom for a solution.
> It must be noted I am not logged into Win2000 as tmsuser, though
> tmsuser is a domain user under which SQLSERVER AGENT runs at the
> subscriber, and tmsuser has full rights on the snapshot share at the
> Publisher (as evident by the successful replications above).
>
|||
> why are you running the merge binary from the command line?
1) To show I'm getting the same results as from WSM.
2) So I can write the results to a log file with the >> redirect
command (so I can post them here) and show the group what I am doing.
3) End users won't have EM, so they need a way to start replication
(which isn't working from WSM, which is why I started this thread)
4) Proof of concept - it SHOULD work, shouldn't it?
thanks
|||[vbcol=seagreen]
This must have to do with accounts / permissions.
I have a couple of theories.
1) Why would executing the Merge agent job from within EM work, while
neither command-line nor WSM work? After all, I generated the
command-line args from the job from EM.
Is EM firing off the merge job under the same userID that I am when I
fire off the command line? (In the example above, both should be
'tmsuser'). How can I tell?
2) When I execute synchronize from WSM, do I have to be logged in to
Windows with the same domain ID that SQLSERVER AGENT (Windows service)
runs under?
Any help appreciated.
Thanks
of the client installation as possible, and running into mega
headaches.
Here's the setup:
Client - MSDE
connects to Publisher/Distributor via VPN
annonymous pull subscription
I can install my MSDE, create the db, logins, etc.
1) Through EM, I can create the subscription through wizard. (selecting
"Available to Synch Manager", "Start immediately"). It works.
Syncronization Manager (type in passwords) synch works.
2) I script the subscription created in 1). Delete subscription and run
script with osql (doesn't run Merge Agent job automatically. Why not? I
even put in an extra line: EXEC sp_start_job @.job_name =
'MERGE_AGENT_JOBNAME'). Go back to EM, right click on subsrciption -
Start Synchronizing. It works. WSM (type in passwords) synch works.
3). Delete subcription and recreate with same script as above. Go
straight to WSM. The subscription is in the list. Synch (type in
passwords). DOES NOT WORK!!! I get the error "the schema script <blah
blah blah> could not be propagated to the subscriber."
Why should I have to run the subscription once through EM before it
will work with WSM? I guess it has something to do with that Merge
Agent job and it needs to be fired off first?
Obviously EM will not be distributed to my end users in far off lands.
I want them to be able to run a script and then synch through WSM. What
is the best way to achieve this?
Much Thanks
answers in line.
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
<richerwin@.ubs-europe.org> wrote in message
news:1109180376.620053.87490@.o13g2000cwo.googlegro ups.com...
> I have my replication "working", though I would like to script as much
> of the client installation as possible, and running into mega
> headaches.
> Here's the setup:
> Client - MSDE
> connects to Publisher/Distributor via VPN
> annonymous pull subscription
> I can install my MSDE, create the db, logins, etc.
> 1) Through EM, I can create the subscription through wizard. (selecting
> "Available to Synch Manager", "Start immediately"). It works.
> Syncronization Manager (type in passwords) synch works.
I take it you are using SQL Authentication in WSM. If so your user will have
to enter the password each time WSM runs. You might want to use intergrated
authentication and enter the user account in the pal on the publisher.
> 2) I script the subscription created in 1). Delete subscription and run
> script with osql (doesn't run Merge Agent job automatically. Why not? I
> even put in an extra line: EXEC sp_start_job @.job_name =
> 'MERGE_AGENT_JOBNAME'). Go back to EM, right click on subsrciption -
> Start Synchronizing. It works. WSM (type in passwords) synch works.
The merge agent doesn't start automatically because you have defined it to
start on demand.
> 3). Delete subcription and recreate with same script as above. Go
> straight to WSM. The subscription is in the list. Synch (type in
> passwords). DOES NOT WORK!!! I get the error "the schema script <blah
> blah blah> could not be propagated to the subscriber."
This means that the subscriber does not have rights to read the snapshot
share. You will have to craft a new snapshot share which does not use the
administrative share (ie \\servername\c$\Program Files\Microsoft SQL
Server\MSSQL\ReplData\UNC). Make sure this new snapshot share has read
permission for the accounts or a group which the merge users are in, and
that this group or user has rights to read the underlying files and folders.
> Why should I have to run the subscription once through EM before it
> will work with WSM? I guess it has something to do with that Merge
> Agent job and it needs to be fired off first?
This does sound odd. Perhaps it is a rights issue.
> Obviously EM will not be distributed to my end users in far off lands.
> I want them to be able to run a script and then synch through WSM. What
> is the best way to achieve this?
> Much Thanks
>
|||
> This does sound odd. Perhaps it is a rights issue.
I create my subscription. Local machine is RICH-VAIO,
Publisher/Distributor is WSCLAN08; database is TMS. At both ends, the
SQL Server is the default instance.
1) I run the following Win2000 DOS BATCH command:
"C:\Program Files\Microsoft SQL Server\80\COM\replmerg.exe" -Publisher
[WSCLAN08] -PublisherDB [TMS] -Publication [pubUser100] -PublisherLogin
[tmsuser] -PublisherPassword [tmsuser] -Distributor [WSCLAN08]
-DistributorLogin [tmsuser] -DistributorPassword [tmsuser] -Subscriber
[RICH-VAIO] -SubscriberDB [TMS] -SubscriptionType 2
-SubscriberSecurityMode 0 -SubscriberLogin [tmsuser]
-SubscriberPassword []
and get the following log:
Microsoft SQL Server Merge Agent 8.00.760
Copyright (c) 2000 Microsoft Corporation
Connecting to Subscriber 'RICH-VAIO'
Connecting to Distributor 'WSCLAN08'
Initializing
Connecting to Publisher 'WSCLAN08'
Retrieving publication information
Retrieving subscription information
The subscription has been marked for reinitialization. Reinitialization
will occur the next time you synchronize this subscription.
The schema script
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
could not be propagated to the subscriber.
Category:NULL
Source: Merge Replication Provider
Number: -2147201001
Message: The schema script
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
could not be propagated to the subscriber.
Category:AGENT
Source: RICH-VAIO
Number: 0
Message: The process could not read file
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre'
due to OS error 1326.
Category:OS
Source:
Number: 1326
Message: Logon failure: unknown user name or bad password.
2) Immediately, I go to EM, right click on my subscription, and select
Start Synchronizing. The last entry in the log history is:
The job succeeded. The Job was invoked by User tmsuser. The last step
to run was step 1 (Run agent.).
3) Immediately, I run the same batch file as above. I get the following
log:
Microsoft SQL Server Merge Agent 8.00.760
Copyright (c) 2000 Microsoft Corporation
Connecting to Subscriber 'RICH-VAIO'
Connecting to Distributor 'WSCLAN08'
Initializing
Connecting to Publisher 'WSCLAN08'
Retrieving publication information
Retrieving subscription information
The merge process is cleaning up meta data in database 'TMS'.
The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
The merge process is cleaning up meta data in database 'TMS'.
The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
Uploading data changes to the Publisher
No data needed to be merged.
Downloading data changes to the Subscriber
4) Successive changes to the data at the subscriber are successfully
uploaded as in 3).
WHAT THE FREAK IS GOING ON WITH Merge Agent?
Please, please, please help. My kindom for a solution.
It must be noted I am not logged into Win2000 as tmsuser, though
tmsuser is a domain user under which SQLSERVER AGENT runs at the
subscriber, and tmsuser has full rights on the snapshot share at the
Publisher (as evident by the successful replications above).
|||just a wild thought here - why are you running the merge binary from the
command line?
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
<richerwin@.ubs-europe.org> wrote in message
news:1109221256.951320.175930@.f14g2000cwb.googlegr oups.com...
>
> I create my subscription. Local machine is RICH-VAIO,
> Publisher/Distributor is WSCLAN08; database is TMS. At both ends, the
> SQL Server is the default instance.
>
> 1) I run the following Win2000 DOS BATCH command:
> "C:\Program Files\Microsoft SQL Server\80\COM\replmerg.exe" -Publisher
> [WSCLAN08] -PublisherDB [TMS] -Publication [pubUser100] -PublisherLogin
> [tmsuser] -PublisherPassword [tmsuser] -Distributor [WSCLAN08]
> -DistributorLogin [tmsuser] -DistributorPassword [tmsuser] -Subscriber
> [RICH-VAIO] -SubscriberDB [TMS] -SubscriptionType 2
> -SubscriberSecurityMode 0 -SubscriberLogin [tmsuser]
> -SubscriberPassword []
> and get the following log:
> Microsoft SQL Server Merge Agent 8.00.760
> Copyright (c) 2000 Microsoft Corporation
> Connecting to Subscriber 'RICH-VAIO'
> Connecting to Distributor 'WSCLAN08'
> Initializing
> Connecting to Publisher 'WSCLAN08'
> Retrieving publication information
> Retrieving subscription information
> The subscription has been marked for reinitialization. Reinitialization
> will occur the next time you synchronize this subscription.
> The schema script
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> could not be propagated to the subscriber.
> Category:NULL
> Source: Merge Replication Provider
> Number: -2147201001
> Message: The schema script
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> could not be propagated to the subscriber.
> Category:AGENT
> Source: RICH-VAIO
> Number: 0
> Message: The process could not read file
>
'\\WSCLAN08\ReplData\unc\WSCLAN08_TMS_pubUser100\2 0050224042747\snapshot.pre
'
> due to OS error 1326.
> Category:OS
> Source:
> Number: 1326
> Message: Logon failure: unknown user name or bad password.
> 2) Immediately, I go to EM, right click on my subscription, and select
> Start Synchronizing. The last entry in the log history is:
> The job succeeded. The Job was invoked by User tmsuser. The last step
> to run was step 1 (Run agent.).
> 3) Immediately, I run the same batch file as above. I get the following
> log:
> Microsoft SQL Server Merge Agent 8.00.760
> Copyright (c) 2000 Microsoft Corporation
> Connecting to Subscriber 'RICH-VAIO'
> Connecting to Distributor 'WSCLAN08'
> Initializing
> Connecting to Publisher 'WSCLAN08'
> Retrieving publication information
> Retrieving subscription information
> The merge process is cleaning up meta data in database 'TMS'.
> The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
> in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
> The merge process is cleaning up meta data in database 'TMS'.
> The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s)
> in MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
> Uploading data changes to the Publisher
> No data needed to be merged.
> Downloading data changes to the Subscriber
> 4) Successive changes to the data at the subscriber are successfully
> uploaded as in 3).
>
> WHAT THE FREAK IS GOING ON WITH Merge Agent?
> Please, please, please help. My kindom for a solution.
> It must be noted I am not logged into Win2000 as tmsuser, though
> tmsuser is a domain user under which SQLSERVER AGENT runs at the
> subscriber, and tmsuser has full rights on the snapshot share at the
> Publisher (as evident by the successful replications above).
>
|||
> why are you running the merge binary from the command line?
1) To show I'm getting the same results as from WSM.
2) So I can write the results to a log file with the >> redirect
command (so I can post them here) and show the group what I am doing.
3) End users won't have EM, so they need a way to start replication
(which isn't working from WSM, which is why I started this thread)
4) Proof of concept - it SHOULD work, shouldn't it?
thanks
|||[vbcol=seagreen]
This must have to do with accounts / permissions.
I have a couple of theories.
1) Why would executing the Merge agent job from within EM work, while
neither command-line nor WSM work? After all, I generated the
command-line args from the job from EM.
Is EM firing off the merge job under the same userID that I am when I
fire off the command line? (In the example above, both should be
'tmsuser'). How can I tell?
2) When I execute synchronize from WSM, do I have to be logged in to
Windows with the same domain ID that SQLSERVER AGENT (Windows service)
runs under?
Any help appreciated.
Thanks
Thursday, February 9, 2012
Analysis Services 2005 Deployment Wizard
Hi,
I used the deployment wizard in the analysis services 2005 to convert
the cube into XML script. Using the SQL Management Studio I opened it
as Analysis Server scripts and used the local host as the system in the
connections windows then loaded the XML script into the Queries window
as a XMLA query. What has to be done after this in order to use it as a
production server?
Thanks,
Somu
Hi,
I was able to connect with a local machine but while synchronising the
dev and production servers i am getting an error "peer prematurely
closed the conn" , " error was encountered in the transport layer" Wat
should i do to over come this...
Thanks,
SOMU
I used the deployment wizard in the analysis services 2005 to convert
the cube into XML script. Using the SQL Management Studio I opened it
as Analysis Server scripts and used the local host as the system in the
connections windows then loaded the XML script into the Queries window
as a XMLA query. What has to be done after this in order to use it as a
production server?
Thanks,
Somu
Hi,
I was able to connect with a local machine but while synchronising the
dev and production servers i am getting an error "peer prematurely
closed the conn" , " error was encountered in the transport layer" Wat
should i do to over come this...
Thanks,
SOMU
Analysis Services 2005 Deployment Wizard
Hi,
I used the deployment wizard in the analysis services 2005 to convert
it into XML script. Using the SQL Management Studio I opened it as
Analysis Server scripts and used the local host as the system in the
connections windows then loaded the XML script into the Queries window
as a XMLA query. What has to be done after this in order to use it as a
production server?
Thanks,
SomuHi,
I was able to connect with a local machine but while synchronising the
dev and production servers i am getting an error "peer prematurely
closed the conn" , " error was encountered in the transport layer" Wat
should i do to over come this...
Thanks,
SOMU|||Hi,
I was able to connect with a local machine but while synchronising the
dev and production servers i am getting an error "peer prematurely
closed the conn" , " error was encountered in the transport layer" Wat
should i do to over come this...
Thanks,
SOMU
I used the deployment wizard in the analysis services 2005 to convert
it into XML script. Using the SQL Management Studio I opened it as
Analysis Server scripts and used the local host as the system in the
connections windows then loaded the XML script into the Queries window
as a XMLA query. What has to be done after this in order to use it as a
production server?
Thanks,
SomuHi,
I was able to connect with a local machine but while synchronising the
dev and production servers i am getting an error "peer prematurely
closed the conn" , " error was encountered in the transport layer" Wat
should i do to over come this...
Thanks,
SOMU|||Hi,
I was able to connect with a local machine but while synchronising the
dev and production servers i am getting an error "peer prematurely
closed the conn" , " error was encountered in the transport layer" Wat
should i do to over come this...
Thanks,
SOMU
Analysis Services 2005 Deployment Wizard
Hi,
I used the deployment wizard in the analysis services 2005 to convert
the cube into XML script. Using the SQL Management Studio I opened it
as Analysis Server scripts and used the local host as the system in the
connections windows then loaded the XML script into the Queries window
as a XMLA query. What has to be done after this in order to use it as a
production server?
Thanks,
SomuHi,
I was able to connect with a local machine but while synchronising the
dev and production servers i am getting an error "peer prematurely
closed the conn" , " error was encountered in the transport layer" Wat
should i do to over come this...
Thanks,
SOMU
I used the deployment wizard in the analysis services 2005 to convert
the cube into XML script. Using the SQL Management Studio I opened it
as Analysis Server scripts and used the local host as the system in the
connections windows then loaded the XML script into the Queries window
as a XMLA query. What has to be done after this in order to use it as a
production server?
Thanks,
SomuHi,
I was able to connect with a local machine but while synchronising the
dev and production servers i am getting an error "peer prematurely
closed the conn" , " error was encountered in the transport layer" Wat
should i do to over come this...
Thanks,
SOMU
Subscribe to:
Posts (Atom)