Thanks, I think I'll have a second app that backs up the data, packs and indexes. I have never used the REINDEX command, but thanks just the same.


>It really depends on how dynamic the tables are. If thousands of records are being created and deleted every day, then you might be able to justify packing and reindexing daily. Yes, more deleted records will slow the app down, just the same as more records, but not until you have A LOT of them. Foxpro is the fastest in the business, and a few (or even a few thousand) records won't make a noticeable difference in performance. I have a table with 4 million records in it whose observable seek time is the same as that of a table with 10 records.
>Generally, packing and reindexing are done weekly and monthly at a time when the system can be taken offline.
>As an aside, reindexing with the REINDEX command causes CDX bloat (your index will get bigger and bigger, and slower and slower). To truly reindex your tables, you should create a routine that destroys your CDX file and recreates all of your indexes from scratch. HTH
>
>
>>Erik,
>>
>>That's the conclusion I had come to. I wanted to make sure I wasn't missing something. The reason I want to reuse the records is to eliminate the need for packing the tables. Since this is a multi-user app. If you don't reuse deleted records, how do you handle packing tables in a multi-user environment? I've done this in the past, but I don't really like like the way I did it. I had procedures that would run the first time the application was run each day. So, whoever was the first person in the app each day would pack, index, archive, etc. all of the tables. Then, reopen them, for shared usage. Should I even worry about the records marked for deletion? Will they slow my app down?
>>
>>TIA
>>
>>
>>>I believe you will find this task impossible, because there is no SQL equivalent to RECALL (RECALL is a very XBASE concept), and the way that views communicate to their underlying tables is through SQL.
>>>
>>>Nancy- there should be no problem getting deleted records into a view, but once they are there, they are not marked as deleted, so you can't RECALL them.
>>>
>>>Chad, my first question is why do you feel you need to reuse records? Generally, (except on a VERY high volume table) disk space is usually not enough of a problem to warrant this.
>>>If you decde you absolutely need to RECALL records, then you will have to do this through the base tables. If you are working primarily throught views, then this is a multi-step process
>>>1. Find the recod in the view that you need to recall, and grab its id
>>>2. Open the base table, RECALL the record with that id, (DON'T clear the fields, or you won't have a way of finding the record later!)
>>>3. Requery the view, LOCATE you recalled record, and do you updating
>>>
>>>Knowing that this is what is involved... do you still want to?
>>>
>>>
>>>>Are you sure you can't? I mean, do you SELECT ... FOR NOT DELETED()? Do you have SET DELETED ON?
>>>>
>>>>>Hi all,
>>>>>
>>>>>I'm using updatable views in an app. I'm wanting to reuse deleted records. The only way I can find to recall the record in the table is actually selecting the table and issuing a RECALL. Doesn't this defeat the purpose of using views? Can I recall a record through the use of a view? If so, How? If not, what's the best way to handle this?
>>>>>
>>>>>TIA