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