Tim,


I think I need to learn how to work with the current state of EDB, and let you do your
job.   Please do not spend any more  time on answering me conserning  the inmemroy DB.

I would like to make one last suggestion. How about a poll about  the feature requests you
have gathered? Something like How important the following features are for your
development....

10 - Can't live without it.
...
5 -  Please, implement this.  
...
3  - Would be useful, but please, do the important stuff first.
...
0 - Not likely I would ever benifit from  this.


Regards, Leslie

Leslie


Look in the extensions ng - Generate in memory table from TEDBTable component on a form

Roy Lambert

Thank you Roy!

Leslie,

<< I would like to make one last suggestion. How about a poll about  the
feature requests you have gathered?  >>

The list of feature requests is over an inch think.  The time it would take
to compile/prioritize such a list would be prohibitive, and probably not
particularly informative for us because we have already committed to a
series of major feature improvements over the next few months, namely the
cached updates, multi-column optimizations, ROW and ARRAY support, and
messaging support.

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie,

<< Inmemory database would be a very good way to optimize performance.  To
do that I need to be able to reference it from the  disk based db and to the
other way around too.  I got the impression that you may be seeing this
mostly from an individual programmer's viewpoint. The way it is at the
moment from the system designer's viewpoint is something like this: "OK,
let's make use of this great inmemory  database feature! Oh wait, I cannot
design, the only use supported is by direct  programming ." >>

It's very simple.  Just use a disk-based database for development work, and
then ship the application so that it uses an in-memory database instead.
You only have to switch a single clause in the CREATE DATABASE statement,
the rest stays exactly the same.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<It's very simple.  Just use a disk-based database for development work, and
then ship the application so that it uses an in-memory database instead.
You only have to switch a single clause in the CREATE DATABASE statement,
the rest stays exactly the same.>>

This is the same, what I have planned to do: Extracting the metadata with EDBManager
changing it to memory db, and loading and running the script from a file  before opening
the database. This should do it for now, but I will only be perfectly happy with it if I
can make deploying metadata changes automated.  

Thank you for your answer,
Leslie

Tim,

<< The list of feature requests is over an inch think.  The time it would take
to compile/prioritize such a list would be prohibitive, and probably not
particularly informative for us because we have already committed to a
series of major feature improvements over the next few months, namely the
cached updates, multi-column optimizations, ROW and ARRAY support, and
messaging support. >>

Clear.  

It would be great if you could be a bit more specific about your planed timing (if you
have any) conserning

- multi-column optimization
- sensitive queries views with joins
- sensitive views (with joins)
- parameters for views
- parameters for derived tables (if I member right they are  implemented as views, so
this could be almost the same as the prior)

I do not expect any promises, just some hints how things would be, if everything goes
ahead as hoped.

Regards,
Leslie

Leslie


This is probably as good as you're going to get

http://www.elevatesoft.com/roadmap?action=list&category=edb


Roy Lambert [Team Elevate]

Roy,

Thank you. My first - and most important question has already been answered. I do not know
why, but for some unexplainable reasons, I thought that the roadmap is not complete/up to
date, so I haven't even looked before sending my post. I should have, appologies to Tim.

Regards,
Leslie

Tim,

<<It would be great if you could be a bit more specific about your planed timing (if you
have any) conserning

- multi-column optimization
- sensitive queries views with joins
- sensitive views (with joins)
- parameters for views
- parameters for derived tables (if I member right they are  implemented as views, so
this could be almost the same as the prior)

I do not expect any promises, just some hints how things would be, if everything goes
ahead as hoped.>>


I guess  the Roadmap actually answers all my questions than.

Regards,
Leslie