thanks again al. i figured the ?occurs after i sent my preivous email and like you ended up with a large count of chr(0). so it sounds like this comes down to a visual inspection through browse. will do that and see what comes up.

k

>Hmm, interesting approach using FILETOSTR(). Looking at your code I'm not sure you're actually testing for CHR( 0 ) (the character whose ASCII code is zero), maybe you're testing for the number 0 (which is ASCII code 48)?
>
>I tested with 2 small known-good free tables on my system:
>

>lcTable = FILETOSTR( {Test Table} )
>?OCCURS( CHR( 0 ), lcTable )
>
>* Results:
>* DSSystem.DBF: 1,351 bytes, 428 CHR( 0 )s
>* FoxUser.DBF: 1,145 bytes, 539 CHR( 0 )s
>

>I haven't looked into this before, but it looks like VFP uses a boatload of CHR( 0 )s as part of a normal, known-good table - maybe for delineating rows and/or columns (?). What I was referring to was CHR( 0 )s in the "payload" of the table i.e. the part visible when you BROWSE it, for example.
>
>With corrupted files I've worked with, CHR( 0 ) appears as a thin, solid-black vertical bar when viewed with BROWSE. Sometimes they occur singly, sometimes across an entire column, or an entire row of the table. If you BROWSE the table, do you see anything like that?
>
>>thanks al. It sounds suspiciously like the chr(0) problem since it only occurred on my computer when i imported the file.
>>
>>So here is my first attempt to scan - which in fact catches one occurrence. I can replace it with " " but i would rather know what i am replacing and in whose record the chr(0) occurs. How would display the record and place using the following code: (or is there a better search code i can use) -tnx k
>>

>>close all
>>cFile = Filetostr("C:\db\prg\menu\myfile.dbf") && Read file
>>For i = 0 To 1 && Loop through control characters
>>IF INLIST(i,0) && look for 0 character
>>WAIT WINDOW ' found here' 
>>LOOP  &&&  dont think i need this but i put it in anyway
>>ENDIF
>>ENDFOR
>>

>>
>>>>A new problem developed on one of our computers - a message flashed by that the .cdx of one of the main database tables could not be found. when i imported that file onto my home computer - i got the same message after a while.
>>>>i experimented with this and removed the cdx, when i restarted, the cdx was duplicated by the program.
>>>>
>>>>is there any cause for alarm - could this be a corrupted database table?
>>>
>>>Superficially it sounds like a problem with a corrupted CDX, not a corrupted table.
>>>
>>>In your experiment, you deleted the CDX, and it was automatically regenerated by the application? This does not happen by default, it sounds like you may have Stonefield Database Toolkit or some similar utility built in to your app. If that's the case, and the utility is rebuilding the CDX from scratch, that's probably the ideal scenario and you shouldn't have to worry about anything.
>>>
>>>There's another way to deal with CDX file corruption if you have a backup of the file (even if it's really old):
>>>
>>>- overwrite the corrupted one with the backup
>>>- open the table in VFP
>>>- issue REINDEX
>>>
>>>If problems with that particular CDX recur, then there could be corrupted data in the associated table (DBF or FPT) files. For example, sometimes CHR( 0 )s get introduced into tables by workstation crashes, network problems etc. Since CHR( 0 ) is sometimes used by the file system as an end-of-file marker this can cause problems. In that case you may need to scan the table files for CHR( 0 )s.