>>>I've got a dbf which is about 3.5MB large, 5400 records which holds our member data ... the typical name, agency, address info.
>>>
>>>We're having some funky problems when trying to print out info through an enduser interface my predecessor wrote which usually works great and no one has touched any of the code lately.
>>>
>>>If we try to select a couple of names to print nametags, labels etc. we're getting unexpected results such as not all names which were selected are printed or we're getting dozens of duplicates for a few names selected.
>>>
>>>I accessed the table from the command window, made a few folks .T. for the "selected" field we have and tried to 'set filter to selected=.t.' and the system either crashes or the results included dozens of duplicates for the several names I set as .T. If I try this with smaller tables, all works fine.
>>>
>>>Could our problems be due to the size of the table getting too large? We house the table in question and end-user program on a network drive on our Netware 3.11 network with 486's being used as our nodes (each with 20mb RAM on them).
>>>
>>>I'm stumbling here, any ideas???
>>>
>>>Many thanks as always,
>>>
>>>Mandy
>>
>>At least, file size cannot create problems. VFP limit is 2GB, and 100M tables are common. Try to reindex you table from scratch, i.e. delete tag all, and then recreate all tags.
>
>Is creating index necessary from scratch, Can't I use 'REINDEX' when after USE ?
Normally there are 2 kinds of corruption (that I know of) relating to indexes. 1) The sort order and keys and 2) The actual index definition(s) in the index header. A REINDEX alone simply takes what is in the header and builds the indexes from that. If the header is damaged, a lot of times, the reindex will not see any problems. By deleting all tags, then you can correct both.