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?