Eduardo,

<< My projects have a lot of "while no eof" routines. Can we use the system
wide Engine, Session, Database and just open a table in raw mode, create a
cursor (like the example), walk trought the records, close the table and
just apply a refresh for TEDBTable or TEDBQuery ? >>

Sure.

<< IOW, as your code, I see that the OpenTable method is the key of the
process if my question will be YES. >>

Yes, OpenTable gives you a cursor on a table or view.  From there you're
free to do all sorts of damage.

--
Tim Young
Elevate Software
www.elevatesoft.com

Johnnie,

<< (Please be unecessary) >>

No, it's not necessary.

--
Tim Young
Elevate Software
www.elevatesoft.com

Terry,

<< 1. Right now, we have to manually st the read only flag on temporary
tables at the os level that we create for reporting purposes to prevent them
from being inserted into the lock file in order to prevent 9480 errors.
Does EDB have ability to either prevent insertion of or remove temporary
tables from the lock file. >>

Yes, EDB's temporary tables don't have this problem anymore.  Temporary
tables are not stored in the catalog, and the lock file doesn't have any
data in it at all anymore.

<< 2. Referential Integrity.  I believe you mentioned that RI will be
supported.  If it is, is there a way to termporarily disable individual RI
rules in order to make the merging of primary key values significantly
easier. >>

RI is supported, yes.  Initially you will not be able to disable the RI at
any time short of dropping the constraints from the table.  Question,
though - when you say "merging primary keys", do you mean merging multiple
rows with the same primary key, or something else ?  I reviewed the
scenarios under which not being able to disable RI would be an issue, and
they were very limited in the sense that even if it were an issue you could
easily do a couple of INSERT/UPDATE statements that accomplished the same
thing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Surjanto,

<< Very interesting, on your initial testing, how many % faster can you get
from this barebone calls ? >>

It's been a while since I did the testing (March), but I believe the
insertion tests were at least 10-15% faster.  The main thing you get away
from is the re-population of the TDataSet record buffers during navigation
and updates.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> No, they will be SQL-based like I said.  However, there will be the option
> of defining functions as DLLs for any system-level code that you need from a
> function.  Any database work can be done very easily in an SQL-based
> procedure or function.

Not if the "database work" is something like replicating all inserts
etc. to a remote destination using a COM port component and ZModem (or
something like that). I strongly suspect direct engine hackery will be
needed in some cases to retain existing DBISAM functionality - hopefully
with the new OO structure that won't be too big a deal.

Eryk

PS: I can think of ways to leverage custom functions in DLLs to get this
sort of thing done as well, but it has "evil hack" written all over it
compared to the elegance of the exisiting engine component events.

Tim,

the current way of programming and designing server side procedures and
events is something I did not find anywhere else. It is an absolute
strength of DBISAM. Therefore we were able to realy write own servers
that blasted away everything else on the market and we were able to move
absolutely all 'inteligence' from the client to the server!

Qualities like that you don't give away easily. Please keep it.

Arnd

Tim Young [Elevate Software] wrote:
> Arnd,
>
> << I hope you don't skip the current way of "procedures". Will this be kept?
>  >>
>
> No, they will be SQL-based like I said.  However, there will be the option
> of defining functions as DLLs for any system-level code that you need from a
> function.  Any database work can be done very easily in an SQL-based
> procedure or function.
>

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:E901C83F-DA79-499C-850E-7803BA28FB37@news.elevatesoft.com...

> No, it's not necessary.

I meant unnecessary for super-duper speed. I'm am looking forward to seeing
your hard work.

-Johnnie

Eryk,

<< Not if the "database work" is something like replicating all inserts etc.
to a remote destination using a COM port component and ZModem (or something
like that). I strongly suspect direct engine hackery will be needed in some
cases to retain existing DBISAM functionality - hopefully with the new OO
structure that won't be too big a deal. >>

Well, it's always possible to add the functionality for custom *server*
functionality to EDB, which I think is what you're asking for.  They would
not have any security at all and would simply be a way of doing RPC with the
database server, thus making them much, much different than an SQL stored
procedure that is managed by the engine in terms of access and security,
etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Arnd,

<< the current way of programming and designing server side procedures and
events is something I did not find anywhere else. It is an absolute strength
of DBISAM. Therefore we were able to realy write own servers that blasted
away everything else on the market and we were able to move absolutely all
'inteligence' from the client to the server!

Qualities like that you don't give away easily. Please keep it. >>

See my reply to Eryk.

--
Tim Young
Elevate Software
www.elevatesoft.com

Johnnie,

<< I meant unnecessary for super-duper speed. I'm am looking forward to
seeing your hard work. >>

EDB is pretty fast as it is with the TDataSet stuff.  I think you'll find
the performance equal to or better than DBISAM in every area.  This is
especially true with BLOBs, which are handled completely differently from
DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com