At 09:01 AM 21/04/2007, you wrote:

>Okay, the DB was corrupt today once again (same index as always). I
>have removed the index now and I am waiting if it crashes again. The
>table is used to send messages (~20 per second) between applications,
>and after receiving they will be deleted - doesn't seem to be a good
>idea. It's interesting that it's always the same index that get's
>corrupt. So the solution could be to mark received messages instead
>and delete them from time to time?

Yes. I'm curious about a few things:

1. Have you been deleting these message records whilst they are
still uncommitted? From your description I could envisage a large
batch of inserts where the earlier message records are deleted before
the batch as a whole is completed and committed.

2. If these are transient records that are written and not read, and
there is no foreign key involved, what is the purpose of indexing the
GUID? What's the purpose of using a GUID at all?

3. Where is the GUID coming from? Is it a UDF? or some mechanism
where the GUID is being created on the application side?

4. Are your applications doing these multiple concurrent batch
inserts in Autocommit transactions?

./heLen