Invalid descriptor index

Good day
I have a simple transactional replication set up between two SQL2000
servers. A single table is replicated with columns of type int, bit and
varchar. The server with the subscription has had SP3 for quite some time,
however after we installed SP3 on the publishing server, we started receiving
an "Invalid descriptor index" error when trying to start the distribution
agent on the publishing server.
Does anyone have an idea why this would happen and how to fix this problem?
Thanks
I have removed the replication and set it up again, however I am still
receiving the invalid descriptor index error...?
"Pieter" wrote:

> Good day
> I have a simple transactional replication set up between two SQL2000
> servers. A single table is replicated with columns of type int, bit and
> varchar. The server with the subscription has had SP3 for quite some time,
> however after we installed SP3 on the publishing server, we started receiving
> an "Invalid descriptor index" error when trying to start the distribution
> agent on the publishing server.
> Does anyone have an idea why this would happen and how to fix this problem?
> Thanks

interview question?

How many tables can be updated with a single update ?I would answer only one
but I'm curious of the exact answer|||even i support one ,but it is correct|||One|||I think one|||zero (where clause finds no rows)

one (duh)

many (updated row cascades to related tables)|||Cascading updates ... hmm ... why didnt I think of that ...

Well .. seems like I lost any chance of getting this job|||What does n mean ... Mr BK|||brett probably means m, not n

m is n + 1

:cool: :cool: :cool: :cool: :cool: :cool: :cool:|||I thought n meant any number...

m to me means many, but infers a relationship as in 1-m

either way...

However, here's a poll type question...how many people use cascade...

I've never...always wanted more control...prefer to delete and insert...

(And keep history)|||Never !!!|||when updates are performed, if you're writing audit records or something, those triggers should fire no matter whether the table being updated is the target table or a related table, right?

oh, and to me, m implies 0 to many, not 1 to many

my answer to the question was "zero, one, or many"

;)|||Originally posted by r937
when updates are performed, if you're writing audit records or something, those triggers should fire no matter whether the table being updated is the target table or a related table, right?

oh, and to me, m implies 0 to many, not 1 to many

my answer to the question was "zero, one, or many"

;)

fair enough...but now we trapse down the logical data modeling path...

things are not always 0-m...could be required to be 1-m...

EDIT: And you didn't answer the cascade question...|||sorry, i assumed my answer to the cascade question would be obvious

i use as much RI (http://evolt.org/RI) as the database supports

unless i'm doing consulting work at a cllient site where there's a DBA with veto on changes or exceptions to his database guidelines...

but that's politics ;)|||That's a great link...love the VW...

And yes, I get the cascade answer...you must be a big IDENTITY kind of guy...

I never thought of cascading as a function of RI though...

but it seems related...

no pun intended|||I use cascading for RI whenever possible. There have been a few times where I have modeled relationships with multiple update paths, and then Cascading fails and I had to resort to triggers.|||Originally posted by Brett Kaiser
That's a great link...love the VW... thanks

actually, when it comes to the natural versus surrogate primary key debate, i tend to favour natural keys, insofar as any candidate key can be called "natural"

however, i have been know to use IDENTITY and its cousins AUTONUMBER, AUTO_INCREMENT, and SEQUENCE from time to time

one of the best articles on the subject, long but very worth the time to read, is Key Points About Surrogate Keys (http://www.rationalcommerce.com/resources/surrogates.htm)|||i think guid is coming up ;)|||You know...|||why I outta...Moe, Larry build a database...

intersection on a single table

Hi all !

I have a table with no keys (temp table) which looks like this :
col1|col2|col3
001|A|.087
001|B|.032
001|C|.345
002|A|.324
002|B|.724
003|A|.088
003|C|.899
001|A|.087
001|A|.234
001|B|.032

As you see, there is some duplicate entries in it. I would like to get a list of all the rows that have the same col1 and col2 BUT different col3 value. The result should return col1=001 col2=A but NOT col1=001 col2=B. I tried a lot of queries with EXISTS, HAVING, etc... but nothing seems to work.

Anyone have an idea how I can do it ?How about something like this?

select distinct test.col1, test.col2, test.col3
from test
inner join
(select col1, col2, count(1) as colcount
from test
group by col1, col2
having count(1) > 1) a on test.col1 = a.col1 and test.col2 = a.col2

Have some fun.|||select col1, col2, col3
from yourtable as t
where 1
< ( select count(distinct col3)
from yourtable
where col1 = t.col1
and col2 = t.col2 )|||Both solution works !

Thanks a lot !