could not execute sp_replcmds

I am working on SQL Server 2000 SP4
I am getting a very strange error on one of my instances;

The process could not execute 'sp_replcmds' on #SERVERNAME#

Replication failure. File 'T:\shiloh\sql\ntdbms\srvrepl\src\replicat.cpp',
line 1677.
(Source: #SERVERNAME# (Data source); Error number: 18759)

In microsoft http://support.microsoft.com/kb/308865 it tells you to apply
SQL SP4, which i have done and re did just incase it wasn't applied properly,
it made no difference to the situations. Ive restarted the intance and the
server and still to no avail.

Last month we did have a situation where our master database went suspect
and this is the first time anything has had to be replicated on that server
since then. The publisher and subscriber database are on the same server.

Thanks.

Was this post helpful to you?

Why should I rate a post?I have a recollection with replication that you have to enable replication before applying SP4 (or re-apply SP4 after enabling replication). You must do this on both the publisher and the distributor. If I recall the sequence correctly, you must do the distributor first and then then publisher.

I know that you said you re-applied SP4, did you do it in accordance with the steps outlined above?

Regards,

hmscott

Corrupted table causes problems

Hi there;
I have a very strange problem. We are running merge replication for a while
and it just stopped working overnight. I am no longer able to create a
snapshot.It stops with the message: An exception occured in the Snapshot
subsystem.
I browsed the newsgroup and someone suggested to run the snapshot from the
commandline. I did that and it run halfway through und terminated with the
message: Column S1Taxvadue4 not found. Which is correct there is no such
column in the database, it is called S1Taxvalue4!
Further investigation revealed that one columns in on of the conflict_...
has a wrong name. Don't ask me why? Well I tried open the table in design
mode to change the name. I am getting the message:
Table 'conflict_...' could not be loaded.
ODBC Error: Cannot insert the value NULL into column'', table '', column
does not allow nulls. Insert fails
Further investigation of the entries in sysobject revealed that this
particular column has NULL in the column usertype. All other columns of this
table have the value 24 in there.
Any ideas on this?
Thomas BornWe are running SQL Server 2000 with SP3 installed on a Windows 2000 Server
machine.
"Thomas Born" <thomas.born@.setac.net.au> wrote in message
news:%23%23gPUB3rDHA.2432@.TK2MSFTNGP10.phx.gbl...
> Hi there;
> I have a very strange problem. We are running merge replication for a
while
> and it just stopped working overnight. I am no longer able to create a
> snapshot.It stops with the message: An exception occured in the Snapshot
> subsystem.
> I browsed the newsgroup and someone suggested to run the snapshot from the
> commandline. I did that and it run halfway through und terminated with the
> message: Column S1Taxvadue4 not found. Which is correct there is no such
> column in the database, it is called S1Taxvalue4!
>
> Further investigation revealed that one columns in on of the conflict_...
> has a wrong name. Don't ask me why? Well I tried open the table in design
> mode to change the name. I am getting the message:
> Table 'conflict_...' could not be loaded.
> ODBC Error: Cannot insert the value NULL into column'', table '', column
> does not allow nulls. Insert fails
> Further investigation of the entries in sysobject revealed that this
> particular column has NULL in the column usertype. All other columns of
this
> table have the value 24 in there.
> Any ideas on this?
> Thomas Born
>

Corrupted index

Hi,
I have a strange problem with an index on one table. The table has an
identity column as its primary key and it is clustered. There are 4 other
non clustered indexes on the table. When I run a DBCC it shows me that there
are several consistency errors regarding one index. The messages all say
something like this
Msg 8951, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
Table error: Table 'ca_CallRecord' (ID 658101385). Missing or invalid
key in index 'IX_ca_CallRecord03' (ID 4) for the row:
Msg 8955, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
Data row (1:2158:0) identified by (RID = (1:2158:0) idca_CallRecord =
19026579) has index values (idca_Account = 1 and dtStart = Nov 11 2004
8:34AM and nDuration = 1266 and nAdjustedCost = 0.0000 and
idca_CallRecord = 19026579).
When I have seen anything like this in the past I have always just dropped
the offending index and recreated it, run DBCC again and everything is
consistent. However when I try that on this database the consistency errors
are shown immediately again when I run DBCC after the create index. It is
only this index that has any consistency problems. The underlying table
shows none.
Thanks in advance for any help.
Wayne
Wayne wrote:
> Hi,
> I have a strange problem with an index on one table. The table has an
> identity column as its primary key and it is clustered. There are 4
> other non clustered indexes on the table. When I run a DBCC it shows
> me that there are several consistency errors regarding one index.
> The messages all say something like this
> Msg 8951, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
> Table error: Table 'ca_CallRecord' (ID 658101385). Missing or invalid
> key in index 'IX_ca_CallRecord03' (ID 4) for the row:
> Msg 8955, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
> Data row (1:2158:0) identified by (RID = (1:2158:0) idca_CallRecord =
> 19026579) has index values (idca_Account = 1 and dtStart = Nov 11 2004
> 8:34AM and nDuration = 1266 and nAdjustedCost = 0.0000 and
> idca_CallRecord = 19026579).
> When I have seen anything like this in the past I have always just
> dropped the offending index and recreated it, run DBCC again and
> everything is consistent. However when I try that on this database
> the consistency errors are shown immediately again when I run DBCC
> after the create index. It is only this index that has any
> consistency problems. The underlying table shows none.
> Thanks in advance for any help.
> Wayne
I can't tell from you post whether the offending index is clustered or
not. But I guess it doesn't really matter. Since your table has a
clustered index, it is known as a clustered table (one without would be
called a heap). The clustered index is the table. All non-clustered
indexes have as a part of their key a reference to the clustered index
key. So the clustered index keys are everywhere.
So try rebuilding the clustered index. Or script out all indexes, drop
them, and re-create.
David Gugick
Imceda Software
www.imceda.com
|||You're missing a row in the non-clustered index 'IX_ca_CallRecord03'
(David - the 8951 error message specifies the index ID of the broken index -
in this case 4). The base table is a clustered index (David - the 8955
identifies the data row that doesn't have a matching index row in the nc
index - in this case it lists both a RID and key value, so the data row must
be from a clustered index. The list of 'index values' in the 8955 are the nc
index keys that are missing from the nc index).
If you've already tried rebuilding this nc index and the error still shows
up, you should run DBCC CHECKDB. If there are no other errors, its possible
that its a bug in nc index maintenance that's already been fixed. What SP
are you running with?
You're best bet for a speedy resultion is to call Customer Support.
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:#NgCK1GyEHA.2624@.TK2MSFTNGP11.phx.gbl...
> Wayne wrote:
> I can't tell from you post whether the offending index is clustered or
> not. But I guess it doesn't really matter. Since your table has a
> clustered index, it is known as a clustered table (one without would be
> called a heap). The clustered index is the table. All non-clustered
> indexes have as a part of their key a reference to the clustered index
> key. So the clustered index keys are everywhere.
> So try rebuilding the clustered index. Or script out all indexes, drop
> them, and re-create.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>

Corrupted index

Hi,
I have a strange problem with an index on one table. The table has an
identity column as its primary key and it is clustered. There are 4 other
non clustered indexes on the table. When I run a DBCC it shows me that ther
e
are several consistency errors regarding one index. The messages all say
something like this
Msg 8951, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
Table error: Table 'ca_CallRecord' (ID 658101385). Missing or invalid
key in index 'IX_ca_CallRecord03' (ID 4) for the row:
Msg 8955, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
Data row (1:2158:0) identified by (RID = (1:2158:0) idca_CallRecord =
19026579) has index values (idca_Account = 1 and dtStart = Nov 11 2004
8:34AM and nDuration = 1266 and nAdjustedCost = 0.0000 and
idca_CallRecord = 19026579).
When I have seen anything like this in the past I have always just dropped
the offending index and recreated it, run DBCC again and everything is
consistent. However when I try that on this database the consistency errors
are shown immediately again when I run DBCC after the create index. It is
only this index that has any consistency problems. The underlying table
shows none.
Thanks in advance for any help.
WayneWayne wrote:
> Hi,
> I have a strange problem with an index on one table. The table has an
> identity column as its primary key and it is clustered. There are 4
> other non clustered indexes on the table. When I run a DBCC it shows
> me that there are several consistency errors regarding one index.
> The messages all say something like this
> Msg 8951, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
> Table error: Table 'ca_CallRecord' (ID 658101385). Missing or invalid
> key in index 'IX_ca_CallRecord03' (ID 4) for the row:
> Msg 8955, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
> Data row (1:2158:0) identified by (RID = (1:2158:0) idca_CallRecord =
> 19026579) has index values (idca_Account = 1 and dtStart = Nov 11 2004
> 8:34AM and nDuration = 1266 and nAdjustedCost = 0.0000 and
> idca_CallRecord = 19026579).
> When I have seen anything like this in the past I have always just
> dropped the offending index and recreated it, run DBCC again and
> everything is consistent. However when I try that on this database
> the consistency errors are shown immediately again when I run DBCC
> after the create index. It is only this index that has any
> consistency problems. The underlying table shows none.
> Thanks in advance for any help.
> Wayne
I can't tell from you post whether the offending index is clustered or
not. But I guess it doesn't really matter. Since your table has a
clustered index, it is known as a clustered table (one without would be
called a heap). The clustered index is the table. All non-clustered
indexes have as a part of their key a reference to the clustered index
key. So the clustered index keys are everywhere.
So try rebuilding the clustered index. Or script out all indexes, drop
them, and re-create.
David Gugick
Imceda Software
www.imceda.com|||You're missing a row in the non-clustered index 'IX_ca_CallRecord03'
(David - the 8951 error message specifies the index ID of the broken index -
in this case 4). The base table is a clustered index (David - the 8955
identifies the data row that doesn't have a matching index row in the nc
index - in this case it lists both a RID and key value, so the data row must
be from a clustered index. The list of 'index values' in the 8955 are the nc
index keys that are missing from the nc index).
If you've already tried rebuilding this nc index and the error still shows
up, you should run DBCC CHECKDB. If there are no other errors, its possible
that its a bug in nc index maintenance that's already been fixed. What SP
are you running with?
You're best bet for a speedy resultion is to call Customer Support.
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:#NgCK1GyEHA.2624@.TK2MSFTNGP11.phx.gbl...
> Wayne wrote:
> I can't tell from you post whether the offending index is clustered or
> not. But I guess it doesn't really matter. Since your table has a
> clustered index, it is known as a clustered table (one without would be
> called a heap). The clustered index is the table. All non-clustered
> indexes have as a part of their key a reference to the clustered index
> key. So the clustered index keys are everywhere.
> So try rebuilding the clustered index. Or script out all indexes, drop
> them, and re-create.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>

Corrupted index

Hi,
I have a strange problem with an index on one table. The table has an
identity column as its primary key and it is clustered. There are 4 other
non clustered indexes on the table. When I run a DBCC it shows me that there
are several consistency errors regarding one index. The messages all say
something like this
Msg 8951, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
Table error: Table 'ca_CallRecord' (ID 658101385). Missing or invalid
key in index 'IX_ca_CallRecord03' (ID 4) for the row:
Msg 8955, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
Data row (1:2158:0) identified by (RID = (1:2158:0) idca_CallRecord = 19026579) has index values (idca_Account = 1 and dtStart = Nov 11 2004
8:34AM and nDuration = 1266 and nAdjustedCost = 0.0000 and
idca_CallRecord = 19026579).
When I have seen anything like this in the past I have always just dropped
the offending index and recreated it, run DBCC again and everything is
consistent. However when I try that on this database the consistency errors
are shown immediately again when I run DBCC after the create index. It is
only this index that has any consistency problems. The underlying table
shows none.
Thanks in advance for any help.
WayneWayne wrote:
> Hi,
> I have a strange problem with an index on one table. The table has an
> identity column as its primary key and it is clustered. There are 4
> other non clustered indexes on the table. When I run a DBCC it shows
> me that there are several consistency errors regarding one index.
> The messages all say something like this
> Msg 8951, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
> Table error: Table 'ca_CallRecord' (ID 658101385). Missing or invalid
> key in index 'IX_ca_CallRecord03' (ID 4) for the row:
> Msg 8955, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
> Data row (1:2158:0) identified by (RID = (1:2158:0) idca_CallRecord => 19026579) has index values (idca_Account = 1 and dtStart = Nov 11 2004
> 8:34AM and nDuration = 1266 and nAdjustedCost = 0.0000 and
> idca_CallRecord = 19026579).
> When I have seen anything like this in the past I have always just
> dropped the offending index and recreated it, run DBCC again and
> everything is consistent. However when I try that on this database
> the consistency errors are shown immediately again when I run DBCC
> after the create index. It is only this index that has any
> consistency problems. The underlying table shows none.
> Thanks in advance for any help.
> Wayne
I can't tell from you post whether the offending index is clustered or
not. But I guess it doesn't really matter. Since your table has a
clustered index, it is known as a clustered table (one without would be
called a heap). The clustered index is the table. All non-clustered
indexes have as a part of their key a reference to the clustered index
key. So the clustered index keys are everywhere.
So try rebuilding the clustered index. Or script out all indexes, drop
them, and re-create.
David Gugick
Imceda Software
www.imceda.com|||You're missing a row in the non-clustered index 'IX_ca_CallRecord03'
(David - the 8951 error message specifies the index ID of the broken index -
in this case 4). The base table is a clustered index (David - the 8955
identifies the data row that doesn't have a matching index row in the nc
index - in this case it lists both a RID and key value, so the data row must
be from a clustered index. The list of 'index values' in the 8955 are the nc
index keys that are missing from the nc index).
If you've already tried rebuilding this nc index and the error still shows
up, you should run DBCC CHECKDB. If there are no other errors, its possible
that its a bug in nc index maintenance that's already been fixed. What SP
are you running with?
You're best bet for a speedy resultion is to call Customer Support.
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:#NgCK1GyEHA.2624@.TK2MSFTNGP11.phx.gbl...
> Wayne wrote:
> > Hi,
> > I have a strange problem with an index on one table. The table has an
> > identity column as its primary key and it is clustered. There are 4
> > other non clustered indexes on the table. When I run a DBCC it shows
> > me that there are several consistency errors regarding one index.
> > The messages all say something like this
> >
> > Msg 8951, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
> > Table error: Table 'ca_CallRecord' (ID 658101385). Missing or invalid
> > key in index 'IX_ca_CallRecord03' (ID 4) for the row:
> > Msg 8955, Level 16, State 1, Server CHIPCCALLTK\ECAS, Line 1
> > Data row (1:2158:0) identified by (RID = (1:2158:0) idca_CallRecord => > 19026579) has index values (idca_Account = 1 and dtStart = Nov 11 2004
> > 8:34AM and nDuration = 1266 and nAdjustedCost = 0.0000 and
> > idca_CallRecord = 19026579).
> >
> > When I have seen anything like this in the past I have always just
> > dropped the offending index and recreated it, run DBCC again and
> > everything is consistent. However when I try that on this database
> > the consistency errors are shown immediately again when I run DBCC
> > after the create index. It is only this index that has any
> > consistency problems. The underlying table shows none.
> >
> > Thanks in advance for any help.
> >
> > Wayne
> I can't tell from you post whether the offending index is clustered or
> not. But I guess it doesn't really matter. Since your table has a
> clustered index, it is known as a clustered table (one without would be
> called a heap). The clustered index is the table. All non-clustered
> indexes have as a part of their key a reference to the clustered index
> key. So the clustered index keys are everywhere.
> So try rebuilding the clustered index. Or script out all indexes, drop
> them, and re-create.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>