Actually, let me clarify this answer:

<< Is it true that a query performed in a client/server setup would always get the most up to date information posted by any other stations even if the server buffers haven't been written to disk. >>

Queries *do* automatically refresh their source tables before being executed, but, again, it is certainly possible that another user updates the rows after the refresh.

Tim Young
Elevate Software
www.elevatesoft.com

<< After having time to think on this further I have less of an issue with local caching in shared files than I do with it being used for a locate function in particular.  It seems reasonable to me that migrating through a file with next and prior would benefit greatly by buffering and without any real issue.  It seems just as reasonable that a locate or findkey would be served best by the server and not at all at the station and that any buffering would be done at the server and therefore would be 100% accurate 100% of the time without the performance hit or network overhead that would be there with next and prior. >>

Locates and FindKeys *do* actually always go directly to the ElevateDB Server, but the session on the ElevateDB Server can still be buffering data that will satisfy the search without having to hit the disk.  If you turn on strict change detection at the session level, then you will get the behavior that you're looking for.

The issue here is that even the ElevateDB Server can share databases with other ElevateDB Server instances or local access.  You can turn on exclusive file access to prevent this, but it doesn't result in the ElevateDB Server coordinating the buffering among the various sessions on the ElevateDB Server:

https://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=rsdelphiwin32&version=10T&comp=TEDBEngine&prop=ExclusiveFileAccess

This is an .ini file setting only for the distributed ElevateDB Server executable, and cannot be modified through the server interface:

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

(under "Configuration Reference").

The next version of ElevateDB actually takes things a step further towards a more traditional database server setup (when you have this setting enabled) and performs all locks locally.  I'll be extending this concept more as things move along with more shared buffering, but for now the behaviors are as-described.

<< In my live example I have a web application where a session may sit idle for 5 or 10 minutes and then perform an operation involving a locate that is minutes out of date.  I have seen examples of 2 minutes but have no idea what the limit might be.  Is there any time consideration with local buffers?
>>

No, there is no time consideration.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks for the answers.  

btw I don't want it to sound like I am unhappy with things in EDB.  Overall I have noticed many differences between ADS and EDB and for the most part I believe EDB to be better for most of them.  I guess it is like the clients I work for in that they don't complain about what works great . . .

BRAVO

<< btw I don't want it to sound like I am unhappy with things in EDB.  Overall I have noticed many differences between ADS and EDB and for the most part I believe EDB to be better for most of them.  I guess it is like the clients I work for in that they don't complain about what works great . . . >>

No problem at all.  Like any database engine, EDB isn't perfect and there are trade-offs within the design choices of any database architecture.   Reports from the field help me figure out how best to keep moving EDB in the correct direction that keeps pace with hardware improvements and how EDB is being typically used.

Tim Young
Elevate Software
www.elevatesoft.com