Replication Setup Issues

While trying to configure replication from and to SQL Server 2000 boxes, I
encountered the following error, which I was not able to get past. The
error is encountered after completing the "Push Subscription Wizard" which
is set to create the database and initialize the schema and data. The
database gets created, but the schema does not.
Does anyone have advice on how to get past this error?
If not, I have questions further on regarding my test environment...
The process could not connect to Subscriber '<SERVERNAME>'.
Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection.
(Source: <SERVERNAME> (Data source); Error number: 18452)
I am connected using windows authentication, and I am an administrator on
both boxes. I can connect to either database and perform any action I want,
but I still keep getting this error. I have not found any way to specify a
login for replication, I assume the job runs either under my login or as SA.
I changed the scheduled task to be owned by SA, and attempted to run it as
both "Self" and "DBO", with no luck. I kept getting the same error. Some
of the IDs that exist in our production database do not exist in the
database we are replicating to, although SA exists, as does my account.
Normally I do not use Enterprise manager for anything and I script
everything out, but the only instructions I had were for EM. Would I be
better off using a script in QA for setting up replication?
Regarding my test environment...
Now, after spending a couple of hours on this error, I decided to go back to
my test environment (where everything worked the first time) and make it
look more like my production environment so I could do another round of
testing. I restored the master database and my 3 database which will be
replicated, but the backups were form different dates and I ran into all
kinds of conflicts. Essentially, SQL Server said the replication
definitions were invalid, and would not let me remove them. Next week, when
time allows, I will be getting a cold backup of the entire database to
attach to, hopefully that will get my test database in a state where I can
do another round of testing.
Am I on the right track with my test environment? What is the proper way to
copy a replication database, and remove the replication?
Any advice will be greatly appreciated.
Are you using sql server logins for the distribution agent, and the
subscriber is set to only allow windows (trusted) authentication? This could
be one cause of the error.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Both of the databases are set up to allow both SQL Server and trusted
authentication. I confirmed by logging into each server as SA, just to be
sure.
I am, however, performing all of the setup using trusted authentication,
under my own account, which has administrative priviledges.
I never specified a logon for the distribution agent, however. Maybe that
is the problem? I was never actually prompted to do so, and was unable to
find where to specify it. I am the owner of the distribution agent
process, and the first process in the scheduled job is set to run as (Self),
so I assume it is running under my account. I tried changing this to DBA,
and I tried changing the owner to SA, neither made a difference.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:exM%23TihUHHA.3652@.TK2MSFTNGP04.phx.gbl...
> Are you using sql server logins for the distribution agent, and the
> subscriber is set to only allow windows (trusted) authentication? This
could
> be one cause of the error.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
>
|||Jim,
just testing all posibilities here so pls can you check what the following
script returns at the subscriber.
Use Master
go
Select @.@.Servername
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Excellent catch. My test database comes back with the production database
name. The question is, how do I correct this, or how do I get the test
database to match my production database configuration?
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:ua103$CVHHA.4784@.TK2MSFTNGP03.phx.gbl...
> Jim,
> just testing all posibilities here so pls can you check what the following
> script returns at the subscriber.
> Use Master
> go
> Select @.@.Servername
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
>
>
>
|||ok, I found this in BOL explaining how to change the server name. The
question is, will this be enough to get the restored database in a testable
state, or am I going about this the wrong way? Tonight I intend to take a
full cold backup from production and reattach to all the databases on test.
How to change to the current server name in the SQL Server 6.5 master
database (ISQL/w)
To change to the current server name in the SQL Server 6.5 master database
1.. Start Microsoft SQL ServerT in minimal configuration mode. In a
command prompt window, from the \Mssql\Binn directory, run:
sqlservr -f
2.. On the Start menu, point to Programs /Microsoft SQL Server 6.5, and then
click ISQL/w.
3.. Enter the sa password, and then click Connect.
4.. Execute SELECT @.@.SERVERNAME to retrieve the former server name.
5.. Execute sp_dropserver to drop the former server.
6.. Execute sp_addserver to add the current server.
7.. Stop SQL Server. In the command prompt window, press Ctrl+C.
8.. Restart SQL Server.
9.. Execute SELECT @.@.SERVERNAME to verify the current server name.
Examples
--Start SQL Server in minimal configuration mode.
--Retrieve the former server name.
SELECT @.@.SERVERNAME
--Drop the server returned from the previous select.
sp_dropserver 'SERVER6X'
--Add the current server.
sp_addserver 'SERVER70', local
--Stop SQL Server.
--Restart SQL Server in minimal configuration mode.
--Verify the current server name.
SELECT @.@.SERVERNAME
"Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message
news:uDG$BKDVHHA.2212@.TK2MSFTNGP02.phx.gbl...[vbcol=seagreen]
> Excellent catch. My test database comes back with the production database
> name. The question is, how do I correct this, or how do I get the test
> database to match my production database configuration?
> "Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
> news:ua103$CVHHA.4784@.TK2MSFTNGP03.phx.gbl...
following
>
|||Jim,
this should be enough to get the subscriber set up. For step 6 you just have
to remember the 'local' switch.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Paul, thank you for the assistance. I'll post back in a couple of days to
let everyone know how I made out.
I have added your site to my online SQL Server library. I have a feeling it
will come in useful.
Thanks again,
Jim
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23Lh$XgDVHHA.4756@.TK2MSFTNGP06.phx.gbl...
> Jim,
> this should be enough to get the subscriber set up. For step 6 you just
have
> to remember the 'local' switch.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
>
|||I was finally able to get my test environment up and running, after renaming
my server, deleting the entries in the distribution database, and updating
the server name in the msdb.dbo.jobs table.
The test environment replicated without any issue, so I do not know why I am
having trouble in production.
Maybe I just need to remove the replication entirely and start from scratch?
Before I go that route, does anyone know what would be likely to cause this
error when trying to run the distribution agent?
The process could not connect to Subscriber '<SERVERNAME>'.
Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection.
(Source: <SERVERNAME> (Data source); Error number: 18452)
"Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message
news:e5aCzMhUHHA.5012@.TK2MSFTNGP04.phx.gbl...
> While trying to configure replication from and to SQL Server 2000 boxes, I
> encountered the following error, which I was not able to get past. The
> error is encountered after completing the "Push Subscription Wizard" which
> is set to create the database and initialize the schema and data. The
> database gets created, but the schema does not.
> Does anyone have advice on how to get past this error?
> If not, I have questions further on regarding my test environment...
> ----
--
> --
> The process could not connect to Subscriber '<SERVERNAME>'.
> Login failed for user '(null)'. Reason: Not associated with a trusted SQL
> Server connection.
> (Source: <SERVERNAME> (Data source); Error number: 18452)
> ----
--
> --
> I am connected using windows authentication, and I am an administrator on
> both boxes. I can connect to either database and perform any action I
want,
> but I still keep getting this error. I have not found any way to specify
a
> login for replication, I assume the job runs either under my login or as
SA.
> I changed the scheduled task to be owned by SA, and attempted to run it as
> both "Self" and "DBO", with no luck. I kept getting the same error.
Some
> of the IDs that exist in our production database do not exist in the
> database we are replicating to, although SA exists, as does my account.
> Normally I do not use Enterprise manager for anything and I script
> everything out, but the only instructions I had were for EM. Would I be
> better off using a script in QA for setting up replication?
> Regarding my test environment...
> Now, after spending a couple of hours on this error, I decided to go back
to
> my test environment (where everything worked the first time) and make it
> look more like my production environment so I could do another round of
> testing. I restored the master database and my 3 database which will be
> replicated, but the backups were form different dates and I ran into all
> kinds of conflicts. Essentially, SQL Server said the replication
> definitions were invalid, and would not let me remove them. Next week,
when
> time allows, I will be getting a cold backup of the entire database to
> attach to, hopefully that will get my test database in a state where I can
> do another round of testing.
> Am I on the right track with my test environment? What is the proper way
to
> copy a replication database, and remove the replication?
> Any advice will be greatly appreciated.
>
|||OK, I removed the replication entirely and started over, with the same
problems as before. It turned out to be an NT account/permissions issue.
The account that runs the SQL Server Agent on the distributor needs to have
access to the subscriber server as well.
Just to repeat the error:
> ----
> The process could not connect to Subscriber '<SERVERNAME>'.
> Login failed for user '(null)'. Reason: Not associated with a trusted SQL
> Server connection.
> (Source: <SERVERNAME> (Data source); Error number: 18452)
I looked at the security event logs on the subscriber server and saw a login
failure when I was trying to push the subscription. The ID that was
erroring out was a local ID on the distributor. The SQL Server Agent was
being run under this local account. Creating the same local account on the
subscriber server and giving it the required permissions, corrected the
problem.