Hi, is this only caching the statement itself or also the data? On clientside or serverside? How does this work in detail?

Any informations available where i can read it in more detail?

Yusuf Zorlu
MicrotronX

Yusuf,

It saves the prepared query, so that EDB doesn't have to prepare it if it is called again.
However, for now don't set it on if you use temporary tables - it's not working correctly in some cases involving temporary tables.

--
Fernando Dias
[Team Elevate]

Yusuf,

<< Hi, is this only caching the statement itself or also the data? On clientside or serverside? How does this work in detail? >>

See here:

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

under "Per-Session SQL Statement and Function/Procedure Caching".

Tim Young
Elevate Software
www.elevatesoft.com

Fernando,

<< However, for now don't set it on if you use temporary tables - it's not working correctly in some cases involving temporary tables. >>

Actually, the issue is with the flushing of temporary table updates, and not having to do with the statement caching.

The issue is that the temporary table updates aren't incrementing the table update counter properly, so the change detection isn't working for temporary tables.  This bug was introduced in the latter part of last year when the I/O changes were being made - I modified the entire codebase to stop relying on file position as a matter of state in order to (eventually) allow for asynchronous file I/O, and as part of that change added an optimization so that temporary tables don't write their headers twice (normal tables use this to check to see if a write was interrupted).  This optimization broke the temporary table change detection (indirectly).

This bug will be fixed by Monday

Tim Young
Elevate Software
www.elevatesoft.com