Sounds interesting...I'll have to give that one some thought.

Thanks!

>Ok, Am I right in thinking that the foreign key table has a lot of
>transactions and is very wide?
>
>If so, you might consider creating a domain table which is just the foreign
>key you need.
>
>Simon
>
>>
>>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
>>
>>
>>
>==========================================================
>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