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