Advice on handling a client's full-text index loss

Hi,
The problem started because the client's hardware malfunctioned and he
needed to move things to a new computer. So, we installed SQL 2000 on the
new computer, ran the SP3 updates, and installed the specific initial
database using our installer.
After that, we restored the database to the data that they had backed up
a while ago. Everything looked good and they ran without full-text searches
for a while. They then decided that they were ready to do the full-text
index populations, so we ran a script designed to get that all squared away.
The problem apparently started when this script attempted to drop the
full-text indexes and relocate them in the appropriate place. I thought I
could work through this, but couldn't find appropriate information for quite
a while. Later, I decided to attempt a manual removal of the full-text
indexes from the sysfulltextindex (sp?) table. There were two rows, with
the first columns having the values of 5 and 6. I removed them, and tried
to clean things up. In that process, I disabled the full-text indexing, and
now it simply will not re-enable.
Reading this newsgroup, I noticed the existence of a script that could
possibly help by manually deleting the traces of the full-text catalogs.
My question is: What is the best next step?
1) Try to make use of the script I just mentioned.
2) Restore the database, copy in the previous full-text data files
to the appropriate directory, and then try to run our script that moves and
re-populates the catalogs?
3) Something else entirely?
Thanks for your help.
John
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.744 / Virus Database: 496 - Release Date: 8/24/2004
John,
I've emailed you charter account directly as resolving this type of a
situation is better handled via direct email. I don't publicly post these
scripts because they require SysAdmin permission level of access and modify
both Registry keys & values as well as SQL Server system tables.
Regards,
John
"John" <jsfishr@.charter.net> wrote in message
news:eMb$LO6jEHA.704@.TK2MSFTNGP09.phx.gbl...
> Hi,
> The problem started because the client's hardware malfunctioned and he
> needed to move things to a new computer. So, we installed SQL 2000 on the
> new computer, ran the SP3 updates, and installed the specific initial
> database using our installer.
> After that, we restored the database to the data that they had backed
up
> a while ago. Everything looked good and they ran without full-text
searches
> for a while. They then decided that they were ready to do the full-text
> index populations, so we ran a script designed to get that all squared
away.
> The problem apparently started when this script attempted to drop the
> full-text indexes and relocate them in the appropriate place. I thought I
> could work through this, but couldn't find appropriate information for
quite
> a while. Later, I decided to attempt a manual removal of the full-text
> indexes from the sysfulltextindex (sp?) table. There were two rows, with
> the first columns having the values of 5 and 6. I removed them, and
tried
> to clean things up. In that process, I disabled the full-text indexing,
and
> now it simply will not re-enable.
> Reading this newsgroup, I noticed the existence of a script that could
> possibly help by manually deleting the traces of the full-text catalogs.
> My question is: What is the best next step?
> 1) Try to make use of the script I just mentioned.
> 2) Restore the database, copy in the previous full-text data files
> to the appropriate directory, and then try to run our script that moves
and
> re-populates the catalogs?
> 3) Something else entirely?
> Thanks for your help.
> John
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.744 / Virus Database: 496 - Release Date: 8/24/2004
>