No, that is not how SDT is supposed to work. You are assuming that the SDT files were not corrupted when the server went down. These files were also open when the server crashed and may have been corrupted. I always assume corruption until proven otherwise.

>Hi Mark,
>
>Now they get further...but now it says it cannot find another cdx file. I am pretty sure it is scusyssi.cdx. This is a free table index. It is in SDT but as a free table. It seems to me that SDT isn't recreating the index for free tables is this correct? I had unfortunately had then deleted all of their cdx's earlier. I sent them a new cdx file for this free table and it works now. I was just wondering if this is how SDT is supposed to work?
>
>Thanks,
>Paul
>
>>You will probably have to send them replacement copies of the DBC, DCX and DCT files. While you are at it send them the 10 SDT files [Coremeta,*, etc]. I say this assuming they do not have a backup to restore from.
>>
>>>I have a client that says they were in the middle of reindexing when the server crashed.
>>>
>>>Now they can't get into the application....they get an error ".DBC internal consistency error".
>>>
>>>I've done a lot of research before I posted this and I tried deleting the foxuser.dbf. I then deleted all the cdx's and had the client run my application with a parameter of "U" which tells my main program to run stonefields update.
>>>
>>>They then get a message that I have never seen...Maybe Doug could shed some light here..."Error# 1529 ; Message: file n:\tts40\data\.dbf already exists as part of a database ; Line# 0 ; Method: MetaMgr.OSDTMGR.UPDATEONETABLE"
>>>
>>>I had them hit ok and it continued on building the rest of the indexes, and then tried to go back into the application.
>>>
>>>I still get this doggone .DBC internal consistency error.
>>>
>>>Thank you for any help. I am really struggling here.
>>>Paul Acton