1st there was dBase then Clipper then in 1995
along came Delphi bringing the BDE with it from
earlier Borland products. Advantage, Topaz,
Halcyon (then called something else) were quick
to market. I prefered Topaz as it had lots of
dBase like functions. Then a friend of mine said
have you tried DBIsam the SQL alone would
be worth it. I downloaded DBIsam trial after
converting a small contacts app using GREP
and 6 tables converted with the supplied tool,
I put an order in as I was blown away by
DBIsam. My cab courier app when I owned it
sold over 2,700 copies to different customers
on top of that after taking to the road with the
DBIsam version cold calling on cab/courier guys
who had purchased dBase, Clipper, and Topaz
versions I sold 1,800 DBIsam copies. I got up
an awful lot of peoples noses with my app, along
comes GPS and a guy who was a guru in that
market called at a couriers at Heathrow Airport
who used my app and it was just what he wanted.
I sold out and he implemented GPS into my app
and yes he uses DBIsam but I have an NDC so
I cant tell. I also hear from our very own Eryk
that the Hong Kong racing club uses DBIsam
and that is one huge body. So all these benchmarks
mean nothing in a real world app. Have you ever
come across an easier to manage CS than DBIsam?
NO there isnt one.
Now a footnote the guy who took my app over he
expanded into haulage GPS stuff and DBIsam is Europe
wide in that app now.
Me I'am retired but working on my own GPS gizzmo
Rita

Roy Lambert wrote:

>Maybe it is. Its possible that Paradox

Exactly speaking the Engine name is BDE. Paradox is only the Database's File structure, it
could also be dBase structure.

> isn't actually creating an index on disc,  just in memory since its been told
> its exclusive and all its saving down to disk is the index definition.

When BDE has setting Local Share=True on, then it is told that it should immediately flush
everything to hard disk while other (network) users may be fetching (sharing) the same
data. So the Paradox indexes must be on hard disk. I used BDE several years in multi user
environments, and it always worked OK with that setting on.

And even if BDE would use some In-memory indexes only, technique that BDE uses to get that
kind of speed would still be interesting. When we think usual DBISAM/ElevateDB
SERVER-usage in C/S mode, there is no one else accessing the database but the Server
process only.

If one could get the Elevate Server to use that same technique that BDE uses, maybe that
could increase the Server's access speed several folds compared to the current situation.

> The omnipotent Tim should know.

I would also be interested to hear anything about this speed difference matter.

I know the sources for BDE are not available from anywhere. But sources for instance
NexusDB are available http://www.nexusdb.com/forums/archive/index.php?t-13559.html  

Maybe someone had time and skills to see what calls actually make the speed difference. It
would be much more interesting to upgrade to new engine versions that also offer some
speed enhancements.

> If you do, make it multi user please.

If someone has some data that would suppose or indicate that "our" databases would make it
better and faster in multi user environments, then maybe I would try to run this test in
multi user mode.
Stan

Stan

>When BDE has setting Local Share=True on, then it is told that it should immediately flush
>everything to hard disk while other (network) users may be fetching (sharing) the same
>data. So the Paradox indexes must be on hard disk. I used BDE several years in multi user
>environments, and it always worked OK with that setting on.

Two points. 1) never blindly believe the documentation 2) I also used BDE/Paradox for several years and it was bloody horrible. The worst was BLOB has been modified but there were others.

>And even if BDE would use some In-memory indexes only, technique that BDE uses to get that
>kind of speed would still be interesting. When we think usual DBISAM/ElevateDB
>SERVER-usage in C/S mode, there is no one else accessing the database but the Server
>process only.

Very wrong. Until Tim brings out the enterprise version both DBISAM and ElevateDB support fileshareing access (which makes me I very happy) so you can't have in memory indices because not everyone may have access to the same memory.

>I would also be interested to hear anything about this speed difference matter.

I'm not overly interested in the speed issue more just curious what's going on with the indices. 80Kb vs c6Mb. I can conceive of no way to achieve that level of compression. I'm sure others can though

>If someone has some data that would suppose or indicate that "our" databases would make it
>better and faster in multi user environments, then maybe I would try to run this test in
>multi user mode.

On the contrary. Going multi user will show some (at least) diminution of speed.

Roy Lambert

Roy Lambert wrote:

> Two points. 1) never blindly believe the documentation

Nobody's asking that either. Yet the documentation is all you have when you start
anything. Own experience starts to accumulate by doing yourself. I do not know what else
you could have?  
LocalShare=True was the mantra read from the docs and also came from our own experience in
Multi User environment.

> 2) I also used BDE/Paradox for several years and it was bloody horrible. The worst was
BLOB has been modified but there were others.

Your folks just did not know howWe had almost 1.000 BDE installations, and *never*
faced the  "BLOB has been modified" error. Index corruptions occurred, but not more often
than with Dbisam. Mostly because of system hangs and power losts.

Some NetFileDir problems, other applications using different BDE versions in the same
machine etc.  These type of problems made us to switch to DBisam.

Speed issues had not been up very much earlier. Now some big tables and operations take
too much time. Sometimes the speed with some operations just gradually starts to freeze
during the working day. And the speed may or may not be better again tomorrow etc. Quite
frustrating while you can't get grab to what could be the actual problem.

When you see that some other DB engines maybe could cut 50% or more off from the execution
time, of course all that makes you to wonder.

> Very wrong. Until Tim brings out the enterprise version both DBISAM and ElevateDB
support fileshareing access

Very much right! All our C/S installations are configured that way that  \DATABASE
directory is not shared, nor accessible for Read/Write operations for anyone else than the
DB server itself. And anyway, if you have FileSharing _available_ in DBISAM, it would be
stupid to use it if you know it will harm your DB that may sometimes rely on in-memory
indexes.

For me it does not matter if the SERVER's Indexes are in RAM or on hard disk as long as
the actual Data is safely on the hard disk.

>  memory indices because not everyone may have access to the same memory.

I do not know exactly what this does mean. I thouhgt that the DB-SERVER process keeps up
one Indexes only, no matter what kind of tasks the Clients may ask from it.

> On the contrary. Going multi user will show some (at least) diminution of speed.

The whole question asks if 'our' DB engines would meet this multi user challenge better
than those other ones.

I was wondering if someone had this kind of information. Starting to arrange and running
multi-user benchmarks is no children's play, an not very many have even tried it. You do
not find easily usable tools for it.  

Currently I just keep wondering the bad looking performance of "our" engines in that
easily repeatable single user test environment.
Stan

"Stan" <stan@not.working.invalid.com> wrote in message
news:2EF70E08-03BD-4D25-A4CB-5CF2FEB5A604@news.elevatesoft.com...
>
> Speed issues had not been up very much earlier. Now some big tables and
> operations take
> too much time. Sometimes the speed with some operations just gradually
> starts to freeze
> during the working day. And the speed may or may not be better again
> tomorrow etc. Quite
> frustrating while you can't get grab to what could be the actual problem.
>

I have experimented on and off with these speed issues in DBISAM, never
could find clear cut answers. For example, I run a query on DBSYS and it
runs much faster than the same query on a tQuery in a Delphi program. Why?
Or I run a query in DBISAM and in Firebird and F runs in 25% of the time.
Why?

>
> Very much right! All our C/S installations are configured that way that
> \DATABASE
> directory is not shared,

In fact, it is not necessary (or advisable IMO) for the client to even know
the location of the database. If you move the database to another folder or
another volume, it should be totally transparent to the client.

nor accessible for Read/Write operations for anyone else than the
> DB server itself. And anyway, if you have FileSharing _available_ in
> DBISAM, it would be
> stupid to use it if you know it will harm your DB that may sometimes rely
> on in-memory
> indexes.
>

What's the big advantage of an in-memory index? I'm not trying to question
what you say, I just don't know.

Robert

Stan,

<< That is not my own invention, I am just refrerring to this benchmark from
couple of years >>

That benchmark had two issues that made the EDB results slightly slower than
they could have been, namely that it was using a CHAR column that requires
padding (instead of a VARCHAR) column and that the indexes were basically
unique, but not defined as such.  Both of these attributes caused the EDB
results to be slower.  Also, since that time, several modifications have
been made to EDB to improve the performance, so I think the EDB performance
is around 1000 rows/sec faster than it was when it was first run.

As for the BDE and NexusDB results, let me just say that it isn't realistic
to expect that kind of performance in a multi-user application and yes, they
are benefitting from specifics of their design that don't apply to either
DBISAM or EDB.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:


> they could have been, namely that it was using a CHAR column that requires
> padding (instead of a VARCHAR) column

I made these changes
   SQL.Add('Name1 VarChar(17),'); // Char --> VarChar
   SQL.Add('Code1 VarChar(1),');

yet that did not seem to have any effect in speed, I keep getting the same numbers.

> and that the indexes were basically unique, but not defined as such.

The original code to create indexes was this:
Sql.Add('create index ix_Name on '+cBenchTableName+' (Name1,Code1,Date1)');

I wonder what would be the command to define this index to be Unique also?

> Both of these attributes caused the EDB
> results to be slower.  Also, since that time, several modifications have
> been made to EDB to improve the performance,
> so I think the EDB performance is around 1000 rows/sec faster than
> it was when it was first run.

That is absolutely the right direction to goYet 1000 rows improvement is not very much,
as originally for instance Nexus made 35162 Rcds/Sec and ElevateDb made 8488 Rcds/Sec

> As for the BDE and NexusDB results, let me just say that it isn't realistic
> to expect that kind of performance in a multi-user application

Of course multi user goes slower in general. But whose engine will choke most in multi
user? Are there some design aspects that would predict DBISAM/ElevateDB would do it
relatively better in multi user?
My thought is also that when DB-SERVER is the only one accessing the DB, then multi user
should not run considerably slower?

> and yes, they are benefitting from specifics of their design that don't
> apply to either DBISAM or EDB.

This is exactly what I am after, the whole basics of DBISAM/ElevateDB engines. Is there
some known, basic bottleneck that prevents them performing better with this kind of test?

The test does quite much standard DB operations, inserting new records, tasks that must be
performed and executed every day. If there are even no work arounds with DBISAM/ElevateDB
how to get around this kind of bottle neck then that is no good news.

Yet if there are any tricks I will gladly test them.
Stan

"Robert" wrote:

> What's the big advantage of an in-memory index? I'm not trying to question
> what you say, I just don't know.

I'm sorry about the confuse. I am not suggesting to use in-memory indexes.

The whole issue rose up when R.Lambert suggested that BDE uses in-memory indexes, and
that's why it is faster in this test.

I am only saying that it does not matter to me if the indexes are in-memory or disk-based
as long as the valuable data remains on the hard disk. And as long as the whole system
runs, quick.  
No one seems to appreciate BDE, and maybe it does not deserve it in general either. Yet it
performs here lightningly fast, and I do not even know what techniques it uses.
Stan

Stan,

<< yet that did not seem to have any effect in speed, I keep getting the
same numbers. >>

With all due respect, I have neither the time or the patience to get into a
long discussion of this benchmark with you right now, nor do I feel that I
need to justify the performance of EDB to you.  We don't do benchmarks
anymore because of this very problem, and I shouldn't have even responded to
you in the first place because I knew that it would result in such a
response.  If you don't like the performance or don't feel that it is
acceptable, then you're free to use another product that is more to your
liking.

--
Tim Young
Elevate Software
www.elevatesoft.com

Stan,

And also, consider this thread closed.

--
Tim Young
Elevate Software
www.elevatesoft.com