Tim

><< I would tend to disagree here. More does not necessarily mean more
>flexible. I, personally, found the DBISAM syntax for using memory tables
>more flexible than ElevateDB's in a strange easier to use way which meant I
>made more use of them. ie flexible in application rather than features. >>
>
>I don't quite understand this statement,

I know Sometimes I don't quite understand it myself. Probably its partly a reaction to change, partly its the entirety of the way in which the memory database/tables work in both systems. I know you had good reasons for going down the standards route but some of the stuff you did in DBISAM was just plain nice and a joy to use.

>and I've seen others voice the
>same. The *only* difference we're talking about here is a:
>
>MySession.Execute('CREATE DATABASE Memory IN MEMORY');

That's cos you're counting a few characters rather than how it feels

>at application startup. That's it No more, no less, and the application
>will work *exactly* the same as with DBISAM (4.x).

Its back to the feel of the thing again - to start with the syntax for using it is different in parts.

Trying to analyse my feelings a bit I think part of it is as I said above - its different - also for the vast majority of us who will only ever need 1 in-memory database per app it feels an unnecessary complication. Then there's the fact that for some operations I have to be in the context of the memory database. Then the memory database doesn't have access to the functions I've built into the "real" database.

In all cases (quite a few of them with your help) I have SPs, scripts or queries to help me but with the old system it was just there. I didn't have to think about it or plan for it. If I suddenly decided that I'd stuff the resultset into memory and play around with it I just did it. I didn't need to worry about even a trivial piece of code.

Roy

Roy,

<< That's cos you're counting a few characters rather than how it feels >>

No, I'm saying stick that statement in every application that you write as
the first thing you do, and you'll never have that feeling again.

<< Trying to analyse my feelings a bit I think part of it is as I said
above - its different - also for the vast majority of us who will only ever
need 1 in-memory database per app it feels an unnecessary complication. Then
there's the fact that for some operations I have to be in the context of the
memory database. >>

I don't see how the context of the database is any different than with
DBISAM.

<< Then the memory database doesn't have access to the functions I've built
into the "real" database. >>

Now you're going someplace else, config-based functions, and that's a
different kettle of fish.  We've discussed the issues with config-based
functions in terms of dependencies, and there just aren't any good solutions
there, yet.  But, again, if you're wanting to use in-memory *tables*, and
not an in-memory database, then just use temporary tables and be done with
it.  You'll be able to mix and match them with normal tables in the same
database and not worry about anything else.

Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< That's cos you're counting a few characters rather than how it feels >>
>
>No, I'm saying stick that statement in every application that you write as
>the first thing you do, and you'll never have that feeling again.

I'd prefer to make sure the memory database is defined in the config rather than set it up at run time. Blithely saying "as the first thing you do" makes it seem a bit easier than it is. In my case the session isn't established until part way through initialisation with users selecting which database they're using. Paths are loaded from an ini file. Then there's the fact that unless you remove the memory database when you close the app (you can't if its multi user can you?) you'll get hit with an error every time you start.


><< Trying to analyse my feelings a bit I think part of it is as I said
>above - its different - also for the vast majority of us who will only ever
>need 1 in-memory database per app it feels an unnecessary complication. Then
>there's the fact that for some operations I have to be in the context of the
>memory database. >>
>
>I don't see how the context of the database is any different than with
>DBISAM.

I freely admitted that I don't really understand my opinion but you're trying to overcome feelings and emotions with logic - its never been know to work so far. You just did too good a job with DBISAM. Anyone making the switch is going to carry the good memories and forget bad ones (if any) as they make the transition.

The positive side is I'm using ElevateDB rather than reverting to DBISAM - I do prefer the new system - honest.

><< Then the memory database doesn't have access to the functions I've built
>into the "real" database. >>

>Now you're going someplace else, config-based functions, and that's a
>different kettle of fish. We've discussed the issues with config-based
>functions in terms of dependencies, and there just aren't any good solutions
>there, yet. But, again, if you're wanting to use in-memory *tables*, and
>not an in-memory database, then just use temporary tables and be done with
>it. You'll be able to mix and match them with normal tables in the same
>database and not worry about anything else.

I think for me you've probably hit the nail on the head. I consider the memory tables as part of the database not as a separate database. Temporary tables are not quite as good as memory tables since they're not "self cleaning" in the event of a crash. Until I can produce absolutely flawless code I like the assurance that once the PCs turned off I've lost the debris.

Roy

Roy,

<< I'd prefer to make sure the memory database is defined in the config
rather than set it up at run time. Blithely saying "as the first thing you
do" makes it seem a bit easier than it is. In my case the session isn't
established until part way through initialisation with users selecting which
database they're using. >>

How do you select a database without connecting a session ?

<< Paths are loaded from an ini file. Then there's the fact that unless you
remove the memory database when you close the app (you can't if its multi
user can you?) you'll get hit with an error every time you start. >>

1) You shouldn't need to load anything from an .ini file for the in-memory
database if, like you say, you want it to always be present.
2) I figured that I didn't have to get into the particulars of how to check
to see if it exists, etc. because the point still stands without them.

<< I think for me you've probably hit the nail on the head. I consider the
memory tables as part of the database not as a separate database. Temporary
tables are not quite as good as memory tables since they're not "self
cleaning" in the event of a crash. Until I can produce absolutely flawless
code I like the assurance that once the PCs turned off I've lost the debris.
>>

I'm personally perplexed by the fixation on temporary tables being left on
disk in the Windows temporary files directory (or wherever).  It's easy
enough to encrypt them in EDB, so I don't see what the hangup is with them
being left on disk in the case of a crash, even if they contain sensitive
data.  If one is so inclined, one could simply do a "delete all temporary
table files" sweep at application startup each time.

If it's a performance concern, then that concern is misplaced.  Temporary
tables do not perform much worse than in-memory tables, contrary to what you
might think.

I'm just trying to make sure that everyone here gets the proper idea about
how this stuff works.  It's often too easy for someone's personal
preferences to become accepted practice simply because they're the most
visible.  Kind of like an urban legend....

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>
> I'm just trying to make sure that everyone here gets the proper idea
> about how this stuff works.  It's often too easy for someone's
> personal preferences to become accepted practice simply because
> they're the most visible.  Kind of like an urban legend....
>

I'm with you on this, Tim.  
When I switched from DBISAM I decided to also switch from MEMORY to
TEMP tables.

I seem to remember that an early build did not actually drop temp
tables for me and while waiting for your (rapid) fix I simply set up a
specific temp folder and deleted any prior files at start up.
That code is still in my app so any crash debris is not an issue.  But
I also drop my temp tables so I have triple cover.  

I've not *noticed* any performance difference using temp tables.

Tim

>How do you select a database without connecting a session ?

That demonstrates an extreemly ElevatedB centric viewpoint The ini file contains a list of valid databases or, I suppose, more correctly name and location of the config files. I'm operating a session / database(s) are one "database" entity system. May not be the best approach but it works for me.

><< Paths are loaded from an ini file. Then there's the fact that unless you
>remove the memory database when you close the app (you can't if its multi
>user can you?) you'll get hit with an error every time you start. >>
>
>1) You shouldn't need to load anything from an .ini file for the in-memory
>database if, like you say, you want it to always be present.

I do - see above

>2) I figured that I didn't have to get into the particulars of how to check
>to see if it exists, etc. because the point still stands without them.

Maybe but leaving part of the story out isn't good practice. In this particular case someone following your advice to add one line of code in introduces an error into an application.

>I'm personally perplexed by the fixation on temporary tables being left on
>disk in the Windows temporary files directory (or wherever). It's easy
>enough to encrypt them in EDB, so I don't see what the hangup is with them
>being left on disk in the case of a crash, even if they contain sensitive
>data. If one is so inclined, one could simply do a "delete all temporary
>table files" sweep at application startup each time.

You have one viewpoint, I have a different one. I personally disagree with anyone who thinks its OK to leave junk on a disk even though there's oudles of space these days in much the same manner that I detest uninstallers that leave a load of crap in the registry or on disk.

>If it's a performance concern, then that concern is misplaced. Temporary
>tables do not perform much worse than in-memory tables, contrary to what you
>might think.

Nope, my own experiments verified that ages ago, at least for the size tables I'm using. I'm guessing its to do with TDataset because my own in-memory string table implementation is about the same speed as ElevateDB for those operations they have in common, however, when accessing via the stringlists its composed of its a lot faster.

>I'm just trying to make sure that everyone here gets the proper idea about
>how this stuff works. It's often too easy for someone's personal
>preferences to become accepted practice simply because they're the most
>visible. Kind of like an urban legend....

Yikes! Ghastly thought. Mind you if I could persuade everyone to move over to my style for formatting code rather than the 'orrible Delphi standard I would be ecstatic.

You may also have noticed that I have, on occasions, recommended temporary files to people.

Roy

Roy,

<< You have one viewpoint, I have a different one. I personally disagree
with anyone who thinks its OK to leave junk on a disk even though there's
oudles of space these days in much the same manner that I detest
uninstallers that leave a load of crap in the registry or on disk. >>

I never said that I think it's "okay".  All I'm saying is that "it happens"
when processes are terminated, and there's an easy way to deal with it.
It's not something that should affect one's decision to use temporary
tables.

Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< You have one viewpoint, I have a different one. I personally disagree
>with anyone who thinks its OK to leave junk on a disk even though there's
>oudles of space these days in much the same manner that I detest
>uninstallers that leave a load of crap in the registry or on disk. >>
>
>I never said that I think it's "okay". All I'm saying is that "it happens"
>when processes are terminated, and there's an easy way to deal with it.
>It's not something that should affect one's decision to use temporary
>tables.

My apologies, I thought you were condoning it.

I'm now confused. I ignore speed (because there isn't much difference), I ignore the self tidying aspect (because its easy for me to clean up in the event of a crash). When and why should I use memory databases/tables?

Roy Lambert

Roy,

<< I'm now confused. I ignore speed (because there isn't much difference), I
ignore the self tidying aspect (because its easy for me to clean up in the
event of a crash). When and why should I use memory databases/tables? >>

When you need something that only needs to reside in memory and must span
multiple sessions within the same process.  Think multi-threaded
applications, or applications that use a single-file briefcase model ala the
EDB backup/restore methods.

Tim Young
Elevate Software
www.elevatesoft.com