Michael

I can't see any application to GLOBAL memory tables. When we need a
temporary table is to "solve" a specific thing for a specific user and
therefore using LOCAL access. And since DBISAM v1 it has memory tables and
v5 certainly will have.

Eduardo

> Interesting - what defines their lifespan? Is it when the app shuts or what?
AFAIK, Global temporary tables live in scope of session, just like memory
tables. When session disconnects they are deleted automatically.
Local temporary tables live in scope of stored procedure or other SQL script,
just like local variables sort of (I wasn't correct in the previous post).
Other users/sessions cannot see your temporary tables. If you need to
have a shared temporary table, then it's not temporary by definition,
because its lifespan cannot be determined.

Michael

Sean,

<< Thanks for the detailed responses. I wasn't asking for any changes to
V5... that probably got lost as the thread progresed or I just wasn't clear
from the start. I just wanted to know if in-memory tables were safe from
"out of memory" errors on a poorly configured PC and Tim didn't directly
address that point the first time around. >>

Sorry about that, I've been doing that a lot lately as I've got a lot to
keep in my head right now.  As far as "out of memory" errors are concerned,
DBISAM in-memory tables are fairly immune from "out of memory" errors due to
the fact that they don't reallocate one large block of memory for storage,
but rather segment the storage into 64KB chunks.  Also, as long as the
client workstation running the application doesn't have an inordinately
small swap file, then it will not have a problem with Windows paging out the
unused memory as needed.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< May I restate the original question in a way, that may be more familiar
to SQL server users: will v5 have temporary tables?
Some SQL engines (including one of your competitors) have thisoption, so you
can have global and local (session local, I understand) temporary tables.
Will v5 have this feature? >>

Not initially, but it isn't very difficult to add so it's something to
consider for one of the earlier minor releases.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

Exactly what I am looking for. I should hire you as my
translator!

Sean

Michael Baytalsky wrote:
> Hi Tim,
>
> May I restate the original question in a way, that may be
> more familiar to SQL server users: will v5 have temporary tables?
> Some SQL engines (including one of your competitors) have this
> option, so you can have global and local (session local, I
> understand) temporary tables. Will v5 have this feature?
>
> The syntax (although I don't like it very much) is:
> CREATE GLOBAL TEMPORARY TABLE
> CREATE LOCAL TEMPORARY TABLE
>
> MSSQL has different name prefixes, like # and ## for these
> things (and I have to admit, that I don't like it either .
>
> The notion of temporary table is somewhat clearer, then
> memory table, cause it really isn't anyones business where the
> data is stored as long as it is accessible fast and will not
> cause a computer to crash in case it gets too large. This is
> IMO exactly what you need, when you need to prepare a report.
>
>
> Regards,
> Michael
>
>
>
> Tim Young [Elevate Software] wrote:
>
>> Sean,
>>
>> One other thing to remember is that in-memory tables will effectively
>> have their memory paged out automatically by the OS as needed, so you
>> might not have much to worry about to begin with.  ElevateDB, like
>> DBISAM, separates the memory table files into blocks of 64k internally.
>>