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?