DBISAM 4 is awesome. It does absolutely everything I desire admirably.
Except one thing. Unicode.

I'm launching into a new project that does require Unicode. So there
aren't that many other options out there (in Elevate world,that is).

I need to know the following things about ElevateDB, maybe from
developers who also have experience with DBISAM 3/4:

1) do you need to deploy any files along with a virgin setup or can
they call be created by the .EXE on first run?

2) did you ever notice any speed difference with DBISAM?

3) I won't be needing any client/server stuff; just plain old local DB,
and won't even be using any SQL. Most of the DB will be mapped onto an
Object Persistence Layer and most data will be manipulated right there.
Okay, not really a question here, just inviting any comments wrt
ElevateDB advantages;

4) robustness will be a main issue (as always, really). Has anyone
noticed any changes compared to DBISAM? How do repairs work? Faster?
Never any issues? Always solved the problem? (I just got a DBISAM
3-using customer who had a power failure -- damage to one table was
irreparable)

Many thanks for all opinions.

Cheers,
Dom

Dom,

> 1) do you need to deploy any files along with a virgin setup or can
> they call be created by the .EXE on first run?

No, you can create everything on first run if you wish.


> 2) did you ever notice any speed difference with DBISAM?

Yes. ElevateDB is in genreal faster than DBISAM, and the difference is even bigger with large tables.


> 3) I won't be needing any client/server stuff; just plain old local DB,
> and won't even be using any SQL.

One of the differences between DBISAM and ElevateDB is the way you create database objects. You are going to use SQL to create the database and the database objects instead of the component methods, but thats pretty simple, using TEDBSession.Execute, for example :
     EDBSession1.Execute('CREATE DATABASE "MyDatabase1" PATH ''c:\MyData'' ');

as well as TEDBBatabase.Execute to create the database objects:
     EDBDatabase1.Execute('CREATE TABLE "Tbl1" (X INTEGER) ');


> 4) robustness will be a main issue (as always, really). Has anyone
> noticed any changes compared to DBISAM? How do repairs work? Faster?
> Never any issues? Always solved the problem? (I just got a DBISAM
> 3-using customer who had a power failure -- damage to one table was
> irreparable)

ElevateDB is really rock solid
The very rare issues I had were very easy to fix with the REPAIR TABLE statement, and i found it very fast.


--
Fernando Dias
[Team Elevate]

Many thanks for your quick reply, Fernando. Most of it is as I expected.

> The very rare issues I had were very easy to fix with the REPAIR
> TABLE statement, and i found it very fast.

That's one of the things that is a bit of a problem in some of my
DBISAM projects. Some very large tables take easily five minutes to
verify. An eternity for many users. I don't know if this can be done in
a separate thread in ElevateDB (accessing the DB in the main thread
while verifying in a background thread)?

Dom,

> I don't know if this can be done in
> a separate thread in ElevateDB (accessing the DB in the main thread
> while verifying in a background thread)?

You can use the VERIFY statement while using the tables, but not REPAIR.
REPAIR requires the exclusive use of the table being repaired.

--
Fernando Dias
[Team Elevate]

Fernando Dias wrote:
> REPAIR requires the exclusive use of the table being
> repaired.

Yes, that's the problem. Speed is of the essence here. It would be nice
if the VERIFY could create a repair strategy in the background, knowing
exactly what needs to be done, which records are damaged, etc.,
speeding up the eventual REPAIR drastically.

Dom,

A VERIFYTABLE() function has been in my wish-list for some time ; not as sophisticated as you had in mind but it would be very handy, though. But I guess Tim must be very busy with the XE2 support and the upcoming new product - WebBuilder - I don't dare to remind him about it at this moment

--
Fernando Dias
[Team Elevate]

Dominique


>1) do you need to deploy any files along with a virgin setup or can
>they call be created by the .EXE on first run?

To qualify Fernando's a bit. You can create *almost* everything in the EXE on first run. What you can't create from the .exe are any external extensions to the engine. Extensions created in SQL can be created by the .exe but anything created in Delphi has to be distributed as a dll - I've got 5 of them.

>2) did you ever notice any speed difference with DBISAM?

Sure did. One of my main motivators for the move was full text indexing and that's much faster.  Other areas I haven't noticed

>3) I won't be needing any client/server stuff; just plain old local DB,
>and won't even be using any SQL. Most of the DB will be mapped onto an
>Object Persistence Layer and most data will be manipulated right there.
>Okay, not really a question here, just inviting any comments wrt
>ElevateDB advantages;

I'm also not using client/server but as Fernando says you will HAVE to use SQL for some things, and its certainly worth looking at for others. Most of my stuff is done via table handling but SQL is better for some things.

>4) robustness will be a main issue (as always, really). Has anyone
>noticed any changes compared to DBISAM? How do repairs work? Faster?
>Never any issues? Always solved the problem? (I just got a DBISAM
>3-using customer who had a power failure -- damage to one table was
>irreparable)

I'd say a bit more robust than DBISAM. However, in development mode, I have managed to trash a table a time or two. I've also managed to do some strange things when backing up and restoring from Acronis.

ElevateDB is different from DBISAM in many areas and its worth trying to spot the differences before they bite you. Have a look through the newsgroups for my name and you'll find a lot of moans from the early days and also a lot of pointers to the differences.

Roy Lambert [Team Elevate]

Roy Lambert wrote:
> What you can't create from the .exe are any
> external extensions to the engine.

External extensions to the engine? Do you have an example?

> I'm also not using client/server but as Fernando says you will HAVE
> to use SQL for some things, and its certainly worth looking at for
> others. Most of my stuff is done via table handling but SQL is better
> for some things.

No problem with the occasional SQL. Just always found it
counter-intuitive to use interpreted text in a compiled application.
Although today it has absolutely zero impact on execution, unless you
put it in a gigantic loop, of course.

> you'll find a lot of moans from the early
> days and also a lot of pointers to the differences.

Looking forward to browse through your moans.

Dominique


>Roy Lambert wrote:
>> What you can't create from the .exe are any
>> external extensions to the engine.
>
>External extensions to the engine? Do you have an example?

Look in the extensions newsgroup

>> I'm also not using client/server but as Fernando says you will HAVE
>> to use SQL for some things, and its certainly worth looking at for
>> others. Most of my stuff is done via table handling but SQL is better
>> for some things.
>
>No problem with the occasional SQL. Just always found it
>counter-intuitive to use interpreted text in a compiled application.
>Although today it has absolutely zero impact on execution, unless you
>put it in a gigantic loop, of course.

The big advantage is that for bulk operations on the tables its easier for it to not interact with the user and hence is a lot faster. You can get pretty near the speed using tables that aren't linked to visual controls, datasources or anything. Its also a lot less coding to say

UPDATE table SET column = CURRENT_TIMESTAMP WHERE column = test

than the equivalent Delphi.

>> you'll find a lot of moans from the early
>> days and also a lot of pointers to the differences.
>
>Looking forward to browse through your moans.

<giggle>

Roy Lambert [Team Elevate]

Dominique,

<< That's one of the things that is a bit of a problem in some of my DBISAM
projects. Some very large tables take easily five minutes to verify. An
eternity for many users. I don't know if this can be done in a separate
thread in ElevateDB (accessing the DB in the main thread while verifying in
a background thread)? >>

I just did a structural verify on a 2+ million row table with 13 indexes in
EDB, and it completed in about 3 minutes.  Of course, the big problem with
larger tables is that the operations become disk-bound in some cases.  In
such cases, it is worth trying to bump up the default table buffer sizes
using ALTER TABLE, which may help alleviate some of the load.  The settings
that you want are these:

[MAX ROW BUFFER SIZE <MaxRowBufferSize>]
[MAX INDEX BUFFER SIZE <MaxIndexBufferSize>]
[MAX BLOB BUFFER SIZE <MaxBLOBBufferSize>]
[MAX PUBLISH BUFFER SIZE <MaxPublishBufferSize>]

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ALTER_TABLE

You can also very easily change these parameters via the EDB Manager Alter
Table task link after clicking on the desired table.

--
Tim Young
Elevate Software
www.elevatesoft.com