Yeah, and unfortunately they are running on 486's on the slowest network I've ever seen. We're also dealing with tens of thousands of records and REINDEXing would take forever...unless...I was able to impliment something that would run at night. I might have to look into that.

Thanks for the input.

>Unless I've misunderstood the fastest way would be to REINDEX surely if the
>index is actually based on a field in another table. The main drawback to
>this approach of referring to other tables in the index must be what
>happens when the other table isn't available and how slow table updates
>must be.
>
>Simon
>
>
>>
>>I appreciate the advice. I realize that having a foreign key is sticking
>>my neck out. However, this is a situation where I'm the third programmer
>>on a massive project and changing the way the data is querried to be
>>displayed means a total re-write of the entire system. (I won't bore you
>>with the details, nor do I have the time to.) I was just wondering if
>>there was a way to keep the foreign key updated without having to re-INSERT
>>the records everytime the data changes. Anyway, I'm not using it for
>>anything 'mission critical'. (mostly for displaying in a browse)
>>
>>Anyway, I thought it was a tricky route, but the only one that would fit in
>>this monster app.
>>
>>Thanks again.
>>
>>>Tom,
>>>
>>>If I understand you correctly you ahve an index on one table that refers
>>to a field in another table, right? This is a disaster waiting to happen.
>>This type of indexing should be avoided at all costs as it presents many
>>problems some of which are not solvable. There is always another way to
>>get the view of the data you want without resorting to aliased fields in
>>the index key.
>>>
>>>Perhaps you can explain why you need this index and we can show you how to
>>do that same thing without the problematic index.
>>>
>>>
>>>
>>>>If anyone has dealt with foreign keys in FPW 2.6 you probably already
>>know my question. I have a tag on a table whose key is set to a related
>>table. (I do this for display ordering and filtering) If the field is
>>changed or modified, such as City being chaged from 'New York' to 'Los
>>Angeles', the foreign tag in the other table will no longer be able to do
>>an optimized locate or filter for that record. It simply gets skipped
>>because the data has changed. I have a work around right now that when the
>>contents are changed it deletes the record and then does a SQL INSERT.
>>That works fine, but is there a more effective way to keep the foreign tag
>>updated?
>>
>>
>>
>==========================================================
>Objective Software http://www.dev-com.com/~objective
>(44)(0)1299-823321 Tel Mobile: 44-(0)976-361760
>(44)(0)1299-879047 Fax
>16 New Street
>Stourport on Severn
>Worcestershire
>England
>DY13 8UW
>Simon P. Lucy
>Support queries http://www.dev-com.com/~objective/support.html