Ian,

<< IB - So, the scenario was - I had opened the table in my app and set a filter to exclude certain records.  The record in question, the first one, was still visible and by my recollection it shouldn't be.  I checked the relevant filtered field and it met the filtered criteria and there fore it shouldn't have been visible.  I fired up edbmgr to check and there the record was with a different value that didn't meet the criteria.  I set/unset the filter a couple of times in the app with the same result. >>

This is a caching issue due to how EDB performs lazy change detection:

https://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=Change_Detection

Any time that you absolutely, positively must *see* (read) the most current changes in the client application's dataset, you must manually call the Refresh method in order to ensure that you see them.  Otherwise, EDB will simply show them to you whenever it needs to read from disk and happens to dump its internal cache (on the server) and pick up the changes.

Again, this is for TDataSet-level *reads* (and related operations like filtering/ranges), not for inserts, updates, or deletes, or query executions.  The issue with performing forced refreshes for these types of operations in EDB is that the TDataSet methods are very granular, and performing a table header read on every single operation is a big performance killer and can cause concurrency issues.  This issue is also a side-effect of how EDB has to operate in order to provide file-sharing access to databases (as opposed to exclusive server-based usage).

Tim Young
Elevate Software
www.elevatesoft.com