Geoff & Jason,

I have never used anything vaguely resembling in-memory tables, but why
support this at the SQL level?

I think it would be more logical to support this at the connection level -
probably through a Boolean property InMemory or something. Any CREATE
TABLE, SELECT etc. done to datasets associated with such a connection
should be done in memory. Maybe a bit difficult for you two to implement,
but easy for us developers to use ;=} It may be stretching it a bit far to
implement support for in-memory triggers and generators, though.

Set

At 20:26 05.12.2000 -0700, you wrote:

>Geoff,
>
>> Good, we just have to workout how we specify the memory table in the
>> SQL. Perhaps something like...
>>
>> SELECT
>> AField INTEGER,
>> BField VARCHAR(60)
>> FROM MEMORY
>>
>> (although this would conflict with any tables called "MEMORY").
>
>I would like to use IBO$MEMORY as the table name.
>
>> I dont know what would be the easiest to insert into your existing
>> parsing routines.
>
>Then, this would also be put in the KeyRelation property for quick, non
>parsing intensive detection.
>
>IBO$ is what I use to denote any tables that are system ones for IBO. So, it
>is a good idea to avoid using anything like this in your applications. I
>rather doubt a contention will arise here.
>
>> > The one limitation that it does have that comes to mind is it
>> > would require a live connection and be impacted by whatever is
>> > going on in the transaction.
>>
>> I guess the live connection may make it less than 100% useful, but you
>> cant have everything.
>
>If there's cheap detection I can actually allow use of this without
>requiring a live connection or transaction. It will just fake them all
>internally. I just didn't want to introduce expensive parsing for things
>that previously didn't require it.
>
>> The Transaction I think could be very useful - you could use the
>> StartTransaction and Commit/Rollback routines to load/save the memory
>> items to file (or whatever).
>
>Although this may be useful for some I think it can probably wait.
>
>> > If anyone is feeling brave and would like to get directly
>> > involved with these developments let me know...
>>
>> Your best bet is to find someone who actually needs/uses memory tables
>> already. I have not used one and so I am not entirely sure of
>> specific requirements. But I'm happy to help where as I can.
>
>I'll take whoever I can get! <g>
>
>Regards,
>Jason Wharton
>CPS - Mesa AZ
>http://www.ibobjects.com
>
>
>
>
>
>
>