My understanding is that the TDataset component's implementation of the Locate function executes a second query to find the record you are trying to locate and then uses a bookmark to find the corresponding record in the query you called Locate on.  Say you have a TIBOTable that you open on a table.  Now go and insert a new row to that table using another query etc or possibly from another instance of the application.  If you then go back to your opened TIBOTable and do a locate searching for that new record, the locate will return true but it will still be sitting on the last row that it was on before the locate.  I believe this is likely because your secondary query that you are running to try and find the record does in fact find the record, but when it then tries to use the bookmark for that record to find it in the original TIBOTable it does not find that record because the TIBOTable has stale data and does not include that new row.  I can't quite follow the IBO Locate code, but my guess is that it sets the result to True if it finds the record with the secondary query and just assumes it will be able to then jump to that record in the original query.  There should be a fix applied where IBO returns false for a Locate call if it was unable to find the requested record in the original dataset even if it was able to find the record in the secondary query you run.  The original Loacate implementation in the BDE and your locate code that tries to find the record by walking the dataset both would return false in this scenario whereas your Locate that tries to be efficient returns true even though it is sitting on the wrong record.  In this case I was able to call Refresh on the TIBOTable to solve this one instance, but I am afraid of bugs that could exist we don't know about yet since it silently fails and returns the wrong result and is sitting on the wrong row.