Hi Tim,

Does that mean - if the developer forgets to drop the table when they're
completed, that the temporary memory table will exist permanently, until
dealt with otherwise? (ie, even after application shutdown)?

Cheers

Adam.

Tim


>Yes, but the point is that the consistency issue is only an issue that can
>be dealt with in terms of personal test. Some may like to use "Memory"
>while others may want to use a different name altogether.

I think you're missing the point here. 1) DBISAM has a memory database built in 2) ElevateDB doesn't. If you followed my suggestion it would. 3) anyone having a problem with in memory databases can be given help and assistance using the "in-built" memory database - they don't have to be told to set one up - its just there.

My bet is the majority of us will never use more than one in-memory database anyway (I know some will which is the reason for the new structure) and having that one in there and pre-defined is one less (albeit minor) migration issue.

I don't think any of us will take exception to the name, and if any do, as you say, they can always "roll their own"

Roy Lambert

Adam


>Does that mean - if the developer forgets to drop the table when they're
>completed, that the temporary memory table will exist permanently, until
>dealt with otherwise? (ie, even after application shutdown)?

Nope - just that there is an entry for the database in the catalog. All tables are "lost" between shutdowns and have to be re-created each time so its like the DBISAM memory database in those circumstances just that you don't have to create the database each time the app starts.

Roy Lambert

Roy,

<< I think you're missing the point here. 1) DBISAM has a memory database
built in 2) ElevateDB doesn't. >>

Yes, but do we really need to go down that road again ?  I've stressed over
and over on these newsgroups that ElevateDB is a very different product from
DBISAM.  It's primary goal is not necessarily DBISAM compatibility, it is to
give our customers a path to the future that is better and more stable than
DBISAM.

<< If you followed my suggestion it would. 3) anyone having a problem with
in memory databases can be given help and assistance using the "in-built"
memory database - they don't have to be told to set one up - its just there.
>>

Does this topic really warrant this type of discussion right now ?  I mean,
we're talking about a name and all of two seconds to create the database
when you need it.  I just do not see what the big objection is.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


I think the main difference here is I'm coming from a viewpoint of making the transition "feel" a bit easier for people, trying to build in a little bit of comfort.

I agree with you that the actual effort involved in setting up a memory database is low BUT its another area of change, and one that I thought it would be easy for you to eliminate.

That was the only concept behind the suggestion.

Roy Lambert

As a ps I've added the code to my data conversion routine to add my own memory database, but I might take it out later and replace all memory tables with temporary tables after reading your other post.

Roy Lambert

Roy,

<< I think the main difference here is I'm coming from a viewpoint of making
the transition "feel" a bit easier for people, trying to build in a little
bit of comfort.

I agree with you that the actual effort involved in setting up a memory
database is low BUT its another area of change, and one that I thought it
would be easy for you to eliminate.

That was the only concept behind the suggestion. >>

I understand, however you have to understand that even minor suggestions can
involve a lot more work on my end than it does on your end in terms of
documentation, etc.   Hence, my resistance.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

Hmmm - thinks - what's documentation - I'm a developer - I don't do documentation


Roy Lambert