Hi

EDB ( V1 and V2 )  is one db-file like .MDB or multi file like DbIsam 4 ?

Enrico,

Multi file like DBISAM. The default extensions are .EDBTbl (table),
..EDBIdx (index), .EDBBlb (blob) and .EDBLck (lock file). Unlike DBISAM
there is also a Catalog file which uses the extension of .EDBCat.

You can review all these file Engine Settings file extensions
properties in the on-line manual at:
http://www.elevatesoft.com/manual?action=mancompprop&id=edb1&product=r&v
ersion=2007&comp=TEDBEngine&prop=UseLocalSessionEngineSettings

--
Regards,
Jan Ferguson [Team Elevate]


Enrico Ghezzi wrote:

<<Hi
<<
<<EDB ( V1 and V2 )  is one db-file like .MDB or multi file like DbIsam
<<4 ?
>>

Enrico

From an elevate emailing in Feb:


4) ElevateDB will have an Enterprise Server version by the end of 2008,
and it will include fail-safe storage, high-concurrency transactions,
large memory buffering, and a single-file database format.

Jan Ferguson [Team Elevate] wrote:
> Enrico,
>
> Multi file like DBISAM. The default extensions are .EDBTbl (table),
> .EDBIdx (index), .EDBBlb (blob) and .EDBLck (lock file). Unlike DBISAM
> there is also a Catalog file which uses the extension of .EDBCat.
>
> You can review all these file Engine Settings file extensions
> properties in the on-line manual at:
> http://www.elevatesoft.com/manual?action=mancompprop&id=edb1&product=r&v
> ersion=2007&comp=TEDBEngine&prop=UseLocalSessionEngineSettings
>

Yes...however I was answering his current question. What if a developer
decides not to purchase/use the Enterprise Server version? I believe
that ElevateDB will retain the multiple file format for the
non-Enterprise Server model although I don't know that for a fact. I'm
sure Tim will let us know the specifications long before that.

--
Regards,
Jan Ferguson [Team Elevate]


Sean McCall wrote:

<<From an elevate emailing in Feb:
<<
<<
<<4) ElevateDB will have an Enterprise Server version by the end of
<<2008, and it will include fail-safe storage, high-concurrency
<<transactions, large memory buffering, and a single-file database
<<format.
<<
<<Jan Ferguson [Team Elevate] wrote:
<<<<Enrico,
<<<<
<<<<Multi file like DBISAM. The default extensions are .EDBTbl (table),
<<<<.EDBIdx (index), .EDBBlb (blob) and .EDBLck (lock file). Unlike
<<<<DBISAM there is also a Catalog file which uses the extension of
<<<<.EDBCat.
<<<<
<<<<You can review all these file Engine Settings file extensions
<<<<properties in the on-line manual at:
<<<<http://www.elevatesoft.com/manual?action=mancompprop&id=edb1&product
<<<<=r&v ersion=2007&comp=TEDBEngine&prop=UseLocalSessionEngineSettings
<<<<
>>

Sean

My intent was not to contradict what you said and I don't believe I did.
I was just letting him know there was a single file solution in the
pipeline because his question implies an interest in a single file
database format. Sorry, but I don't get what point you are trying to
make with the rhetorical question.


Jan Ferguson [Team Elevate] wrote:
> Yes...however I was answering his current question. What if a developer
> decides not to purchase/use the Enterprise Server version? I believe
> that ElevateDB will retain the multiple file format for the
> non-Enterprise Server model although I don't know that for a fact. I'm
> sure Tim will let us know the specifications long before that.
>

Sean:

<<My intent was not to contradict what you said and I don't believe I
<<did.

No you didn't...not really, although it did make me do a double-take
and respond to you. Not an issue...you did point out something which
might be of interest to Enrico.

<<Sorry, but I don't get what point you are trying to make with the
<<rhetorical question.

My point was to indicate that the Enterprise Server version would
*possibly* not take away the multiple file format (of course I don't
know for sure because Tim has not made that public), in case that was
Enrico's ultimate desire. In my reading of his post I didn't get the
implication of an interest in a single file format from his question.
He simply asked which format EDB used. In my case, if I were to ever
ask a question like that, it would be to shy away from anything with a
single-file format as I personally find them less than desirable for my
projects.

Hope this helps to clear up my response.

--
Regards,
Jan Ferguson [Team Elevate]

> ...In my case, if I were to ever
> ask a question like that, it would be to shy away from anything with a
> single-file format as I personally find them less than desirable for my
> projects.

This is interesting. I am a long time user of DBISAM (from V2 days) and
I have recently become a bit jaded with it.In particular I am having
problems with many users trying to connect to a central database. And by
'many users', I mean 3 or 4. I really need to allow for 20 or so users,
and as far as I can see, that is not practical. It is simply too slow.

I have implemented the C/S version, but that does not seem that much
faster. Mind you, I have not implemented any stored procedures, or
anything like that, so I have a few avenues to explore there.

I have a feeling that the problem is the multi-file approach that DBISAM
uses. In particular, problems with the way DBISAM locks records. It
locks too much, which slows down other users trying to access the same
table. I believe a lot of the problem stems from the fact that Windows
handles the file locking - not DBISAM. So it seems to me a better
approach to go to a single file - where DBISAM can control all record
locking. This is the way MS Access works, and I have to say that it
seems a lot faster. MS Access seems to work a lot better (faster, more
users, etc), and since that uses a single file, perhaps that is the answer.

I might be wrong on a few of these assumptions, so I welcome being
corrected. I would really like to know why you find single file
databases less desirable than multi-file ones.

Kerry,

<< I have a feeling that the problem is the multi-file approach that DBISAM
uses. >>

No, it isn't.  An easy to way to verify this is to take the same
application, run multiple instances of it on the same machine, and see what
the performance is.  If it's much faster than the C/S version, then the
issue is how the application interacts with the database server.

In your case, you're simply probably trying to do too much "local" access
with a remote C/S session.  Lookups, calculated fields, and many other
things in Delphi's TDataSet architecture simply don't perform well over a
remote session due to the fact that they're extremely chatty, and cause a
lot of request/response turnaround time.

<< In particular, problems with the way DBISAM locks records. It locks too
much, which slows down other users trying to access the same table. I
believe a lot of the problem stems from the fact that Windows handles the
file locking - not DBISAM. So it seems to me a better approach to go to a
single file - where DBISAM can control all record locking. This is the way
MS Access works, and I have to say that it seems a lot faster. MS Access
seems to work a lot better (faster, more users, etc), and since that uses a
single file, perhaps that is the answer. >>

MS Access uses OS locking also, and there's nothing inherently wrong with OS
locking in terms of local performance.  In fact, Access performs a *lot*
more locking than DBISAM.  It has to lock every single page in the database
when it reads or writes to that page.  DBISAM does not require that amount
of locking.

Furthermore, a single-file format has nothing to do with how the locking is
performed.  The two are completely unrelated.  A single-file format is only
useful in terms of fail-safety, and only if fail-safety is implemented.
Access and many other single-file formats do not implement fail-safety, so
it doesn't even apply.

We have customers with as many as 75 users on a single installation using
the DBISAM Database Server.  You have to actually spend some time thinking
about how the application is written, however, when you get above 25-30
concurrent users really pushing the database hard.  And, you have to
differentiate between communications performance issues, and database server
performance issues.  The two are not the same thing, and require different
solutions.

--
Tim Young
Elevate Software
www.elevatesoft.com

> << I have a feeling that the problem is the multi-file approach that DBISAM
> uses. >>

> No, it isn't.  An easy to way to verify this is to take the same
> application, run multiple instances of it on the same machine, and see what
> the performance is.  If it's much faster than the C/S version, then the
> issue is how the application interacts with the database server.

Ok - thanks makes things a bit clearer. And I would have hated to move
away from DBISAM - there is so much effort and time invested in it!

Just as a matter of interest, we are still using MS Access 97 here at
work for a particular application. There are 3 users, 100,000+ records,
plus a lot of forms, reports, queries, etc. It was written by a
non-programmer, and is very poorly done. Actually, that is the main
reason we still use it - is was so poorly done we have a hard time
trying to work out what he is doing, so we just let it go. Anyway, that
application is much faster than my DBISAM application with 5,000 records
and 2 users.

The spec for my application is it must be usable with 20 users and
100,000 records. Currently, I have no problem meeting that spec with one
user - even over a network. I test with 500,000 records and it is ok.
The problem is when we add even one user, it slows dramatically.

I was clutching at straws with the multi file/single file thing. I am
glad you do not think it a problem.

Since DBISAM is basically dead, and there are some indications that
ElevateDB might be faster, I am thinking seriously about moving to that.
Your comments would be appreciated.

Kerry,

<< Just as a matter of interest, we are still using MS Access 97 here at
work for a particular application. There are 3 users, 100,000+ records, plus
a lot of forms, reports, queries, etc. It was written by a non-programmer,
and is very poorly done. Actually, that is the main reason we still use it -
is was so poorly done we have a hard time trying to work out what he is
doing, so we just let it go. Anyway, that application is much faster than my
DBISAM application with 5,000 records and 2 users. >>

Then you're most likely not doing something correctly.  There's no way that
Access 97 is "much faster" than DBISAM 4, especially with record and user
counts that small.

We manage our entire company using DBISAM.  I'm talking GB's of data, 94
tables, hundreds of thousands of rows, and many users.  These newsgroups,
our web site, and our internal systems all run live against the same
database.  And we're probably a smaller example compared to some of our
customers.

<< The spec for my application is it must be usable with 20 users and
100,000 records. Currently, I have no problem meeting that spec with one
user - even over a network. I test with 500,000 records and it is ok. The
problem is when we add even one user, it slows dramatically. >>

And this is C/S, or multi-user, file-sharing ?  What slows down,
specifically ?  It's really hard to even respond to what you're saying
without any idea of what it is that is exactly slow.

<< Since DBISAM is basically dead, and there are some indications that
ElevateDB might be faster, I am thinking seriously about moving to that.
Your comments would be appreciated. >>

DBISAM is not dead.  The introduction of the support plans will allow us to
keep DBISAM going for some time, and was the entire purpose behind them.  As
for ElevateDB being faster, yes, overall it is faster.  However, if you're
seeing performance issues with DBISAM, then moving the exact same code to
ElevateDB is not going to solve your problem for you since you'll most
likely still experience the same performance issues.  IOW, the cause of the
issues is not the database engine, but most likely how you're using it.
Neither DBISAM nor ElevateDB can optimize your database design for you, it
has to be done correctly so that you take into account the architecture and
how you are accessing the database.  You need to make sure that you have the
proper indexes available for locates, lookups, filters, query joins and
where conditions, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com