>Looking at my error handling code to try an research a "locking up" problem. Seeing if any errors produce no message and then do a retry. the 1707 error does a retry without an error message. 1707 is "The structural index file associated with a table file could not be found." Any thoughts on why there would be a retry on a 1707?
>
>Thanks
>
>Brenda

Hey Brenda,
I use Stonefield Database Toolkit to recreate any missing index via an error routine. So for instance, assuming ON ERROR is set to the routine below, if you open your table and its missing an index, this triggers a 1707 and sends you to the error routine. A CASE statement evaluates the error# and calls the the SDT function to recreate the missing index, then the error routine passes control back to the USE < table > with a RETRY. Voila! Index issue is fixed and the user never had to be bothered.

Steven-

Here's the code:
------------------
procedure ErrorHandler
parameters tnError, tcMessage, tnLineno
do case

* If an index error occurred, reindex the table.
* 5 = record out of range
* 19 = index doesn't match DBF
* 20 = record not in index
* 23 = index expression too big
* 26 = table isn't ordered
* 112 = invalid key length
* 114 = index file doesn't match DBF
* 1124 = key too big
* 1683 = tag not found
* 1707 = structural CDX not found
* 1567 = primary key invalid

case inlist(tnError, 5, 19, 20, 23, 26, 112, 114, 1124, 1683, ;
1707, 1567) and not empty(oMeta.oSDTMgr.cAlias)
oMeta.oSDTMgr.Reindex(oMeta.oSDTMgr.cAlias)
return ccMSG_RETRY

* If the table or memo is corrupted (15 = not a table, 41 = memo missing or
* invalid), repair it.

case inlist(tnError, 15, 41) and not empty(oMeta.oSDTMgr.cAlias)
oMeta.oSDTMgr.Repair(oMeta.oSDTMgr.cAlias)
return ccMSG_RETRY
endcase
endproc