Showing posts with label subscription. Show all posts
Showing posts with label subscription. Show all posts

Monday, March 19, 2012

8198 error

sql2k sp3
win2k sp4
Im trying to create a Pull Subscription for replication and get "Error 8198:
Could not obtain information about Windows NT group/ user 'domain/ user'".
I read this:
http://support.microsoft.com/?kbid=834124
But both boxes are in the same domain and the same subnet. Both use the same
domain admin account for SQL Server and the Agent accounts.
I also read this:
http://support.microsoft.com/?kbid=838460
But Im not about to install sp4 Beta on anything. SA is the owner of all the
jobs.
Is there anything else I can do?
TIA, ChrisR
we are receiving these all over the place where I work. They are normally
solved by changing the job owner to sa and restarting the job. It seems that
a recent update has caused this problem/behavior.
"ChrisR" <noemail@.bla.com> wrote in message
news:%237FEr0PTFHA.3696@.TK2MSFTNGP15.phx.gbl...
> sql2k sp3
> win2k sp4
> Im trying to create a Pull Subscription for replication and get "Error
> 8198:
> Could not obtain information about Windows NT group/ user 'domain/ user'".
> I read this:
> http://support.microsoft.com/?kbid=834124
> But both boxes are in the same domain and the same subnet. Both use the
> same
> domain admin account for SQL Server and the Agent accounts.
> I also read this:
> http://support.microsoft.com/?kbid=838460
> But Im not about to install sp4 Beta on anything. SA is the owner of all
> the jobs.
> Is there anything else I can do?
> TIA, ChrisR
>
|||It would have been easier if that had been it. I didnt realize that these
two boxes are in they're own little world, and that connections to them can
be rather difficult.
Thanks Hillary.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23B19ZdQTFHA.3464@.tk2msftngp13.phx.gbl...
> we are receiving these all over the place where I work. They are normally
> solved by changing the job owner to sa and restarting the job. It seems
> that a recent update has caused this problem/behavior.
> "ChrisR" <noemail@.bla.com> wrote in message
> news:%237FEr0PTFHA.3696@.TK2MSFTNGP15.phx.gbl...
>

Sunday, March 11, 2012

8144 error: sp_MSaddinitialarticle has too many arguments

I have two servers that I am connecting with Merge replication (SQL2k).
SERVER1 is the publisher and pushes a subscription to SERVER2. After the
snapshot is created, the Merge Agent runs but gets the following error:
Procedure or function sp_MSaddinitialarticle has too many arguments
specified. (Source SERVER2 (Data source); Error number: 8144)
The process could not deliver the snapshot to the Subscriber. (Source:
Merge Replication Provider (Agent); Error number: -2147201001)
Any ideas?
William Schmidt
This error is usually caused by schema changes that are not propagated from
Publisher to Subscribers. Can you check that and verify that schemas are up
to date on both servers.
"Wm" wrote:

> I have two servers that I am connecting with Merge replication (SQL2k).
> SERVER1 is the publisher and pushes a subscription to SERVER2. After the
> snapshot is created, the Merge Agent runs but gets the following error:
> Procedure or function sp_MSaddinitialarticle has too many arguments
> specified. (Source SERVER2 (Data source); Error number: 8144)
> The process could not deliver the snapshot to the Subscriber. (Source:
> Merge Replication Provider (Agent); Error number: -2147201001)
> Any ideas?
> William Schmidt
|||Yes, schema is the same. Detached SERVER1 DB, copied the mdf/ldf to SERVER2,
then reattached both DBs. So, right now, both DBs are identical in schema
and data. Only difference is that I've been trying to set up replication
from SERVER1, whatever that may do to the DB. However, I am (apparently)
successful at removing replication between tries.
"Mark" wrote:
[vbcol=seagreen]
> This error is usually caused by schema changes that are not propagated from
> Publisher to Subscribers. Can you check that and verify that schemas are up
> to date on both servers.
> "Wm" wrote:
|||can you do a select @.@.version on both sides of your replication solution?
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
"Wm" <Wm@.discussions.microsoft.com> wrote in message
news:E2B4FE2E-BB1D-448B-9E79-14691E4BFF80@.microsoft.com...
> I have two servers that I am connecting with Merge replication (SQL2k).
> SERVER1 is the publisher and pushes a subscription to SERVER2. After the
> snapshot is created, the Merge Agent runs but gets the following error:
> Procedure or function sp_MSaddinitialarticle has too many arguments
> specified. (Source SERVER2 (Data source); Error number: 8144)
> The process could not deliver the snapshot to the Subscriber. (Source:
> Merge Replication Provider (Agent); Error number: -2147201001)
> Any ideas?
> William Schmidt
|||Hmmm...
8.00.760
8.00.818
"Hilary Cotter" wrote:

> can you do a select @.@.version on both sides of your replication solution?
> --
> 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
> "Wm" <Wm@.discussions.microsoft.com> wrote in message
> news:E2B4FE2E-BB1D-448B-9E79-14691E4BFF80@.microsoft.com...
>
>
|||I personally dont think that @.@.Version is a big issue here. The error that
you are presenting is caused sometimes when in the article properties you say
you would use spIns_... and that procedure doesnt exist in the subscriber
database.
Technically one would expect to see an error like Stored procedure not found
or something similar, but I have seen instances where you will see too many
parameters error rather than procedure not found error.
Make sure that you have all procedures in Subscriber.
-Nitin
"Wm" wrote:
[vbcol=seagreen]
> Hmmm...
> 8.00.760
> 8.00.818
> "Hilary Cotter" wrote:
|||There could be a problem if your replicated database(s) use a binary collation. This is covered in http://support.microsoft.com/kb/814032
I'm not sure that this is what is going on, but it happened to me...
The solution for me was to install the MS03-031 SQL patch.
HTH
jg

Quote:

Originally posted by Wm
Hmmm...
8.00.760
8.00.818

|||Thanks Hilary; thanks Nitin! Here is the culprit:
When Microsoft created one of the post-SP3 hotfixes, they changed the stored
procedure sp_MSaddinitialarticle by adding a parameter called
@.published_in_tran_pub. So when SERVER1 (build 818) tries to set up
replication with SERVER2 (build 760), the above mentioned stored procedure is
called on SERVER2 with too many parameters. So it IS a version
incompatibility after all.
I can't find the hotfix files anywhere so when I get a chance, I'm going to
reinstall SQL Server 2k on SERVER1 and bring it up to build 760 level (SP3a).
"Nitin" wrote:
[vbcol=seagreen]
> I personally dont think that @.@.Version is a big issue here. The error that
> you are presenting is caused sometimes when in the article properties you say
> you would use spIns_... and that procedure doesnt exist in the subscriber
> database.
> Technically one would expect to see an error like Stored procedure not found
> or something similar, but I have seen instances where you will see too many
> parameters error rather than procedure not found error.
> Make sure that you have all procedures in Subscriber.
> -Nitin
>
> "Wm" wrote: