If you want an in-memory table the easiest way to implement it would be to
do something like this:

Use a TIB_Query and specify a special code in the SQL property to signify
that an in-memory table was desired. Then, what it would do is allow you to
insert your records, etc.

With a little bit of work I think I could pull it off.

The SQL would have to provide the physical layout of the columns. If
CachedUpdates were enabled then it may even be possible to do something with
it more handy. Using cached updates essentially is an in-memory table you
are just basing the layout of the columns on a prepared select statement.

I already have the capability built into IBO to fake a prepared statement
without having to actually prepare it.

How does this sound?

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. To isolate it from transactions you would just give it its own
transaction. In version 4 (perhaps not in the initial release but soon
afterwards) I will have IBO such that it will tolerate the connection going
away during a cached updates session. This could open up opportunities to
make the in-memory dataset that much more functional.

I have also been thinking of doing a cached table where my dataset is able
to load and unload a dataset to a local file. I also want to build in
client-side sorting of data. I think these are also essential features of
in-memory datasets.

If anyone is feeling brave and would like to get directly involved with
these developments let me know...

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Geoff Worboys" <geoff@...>
To: <IBObjects@egroups.com>
Sent: Tuesday, December 05, 2000 6:11 PM
Subject: Re: [IBO] Suggestions for IBO v4


> > would be nice to have an "in memory table" component simulating
> > the properties and behaviour of TIB_Query (with a fields editor).
>
> I had a thought about this, but have not investigated the full details
> yet...
>
> I have a stored procedure that takes FromDate and ToDate parameters
> and cycles through the dates in the range, returning a record for each
> date. It would be easy enough to create an equivalent procedure that
> does the same for integers - giving a skeleton of a table with an
> integer primary key (but no other fields).
>
> At the client you create additional fields using Calculated fields.
> All we need then is for the Calculated fields to be (optionally?)
> editable - this was discussed recently, I dont know what the outcome
> was. The calculated fields can then be populated from a stringlist or
> whatever - the "in memory" table.
>
> There are obviously details to be worked out, but how does something
> like this sound? It provides a form of in memory table that *may* be
> able to be implemented with minimal impact to the underlying code.
>
> Jason, what do you think?
>
> Geoff Worboys
> Telesis Computing
>
>
>
>
>