Our DBISAM version is 3.30, and the apps are mainly operating in C/S
mode.
Currently one of my clients has 150.000 items on their Spare Parts
register, uses as spare parts shops's POS system. That seem to run fine
with 3..4 simultaneous users.

Now the client would want to import yet another spare part register and
that would mean adding 600.000 new records.

The server is some Intel server with 4 Cores, so there is enough
processing power. I wonder if also the old 3.30 DBISAM Server-process is
able to utilize all the power those 4 cores are offering?

Does anyone have any warnings, or maybe success stories when the old
3.30 version has this amount, 750.000 records to hold?

If someone can give good reasons why that amount of data would run
better on DBISAM 4.x or 5.x versions, then we will think about.

Thanks for any comments.
-Asko S.

Asko


There isn't any DBISAM V5 but it would almost certainly be "better" under ElevateDB Tim's new database.

I don't know if you would get any improvements going from V3.30 to V4.26 apart from the fact that the latter is more up-to-date and has a few more features. Maybe one of the people who do run large databases can comment.

Roy Lambert

Asko,

<< Does anyone have any warnings, or maybe success stories when the old 3.30
version has this amount, 750.000 records to hold? >>

Well, for starters you'll want to use FastMM4 as the memory manager in the
database server in order to take advantage of the multiple processors
without having the Delphi memory manager holding up things.  But, with 3.x
you'll need to have the source code to the product in order to modify the
database server.

<< If someone can give good reasons why that amount of data would run better
on DBISAM 4.x or 5.x versions, then we will think about. >>

ElevateDB will be better with larger amounts of rows due to its design.  You
can find out more information on ElevateDB here:

http://www.elevatesoft.com/edb_prodinfo.htm

The obvious benefit to using a newer product is that 3.x is no longer
getting any updates, so you'll be current with a product that is actively
being developed and improved.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:
>
>
> Well, for starters you'll want to use FastMM4 as the memory manager in the
> database server in order to take advantage of the multiple processors

This alone _may_ be good enough reasons!

I'll have to check what that FastMM4 will require in general, when
thinking about all the 3rd party components we are using. Or maybe there
is nothing to worry about, just stick the new memory manager in to
Delphi?

> << If someone can give good reasons why that amount of data would run better
> on DBISAM 4.x or 5.x versions, then we will think about. >>
>
> ElevateDB will be better with larger amounts of rows due to its design.  You
> can find out more information on ElevateDB here:

Does this mean that your primary suggestion is to go directly from 3.30
--> ElevateDB? And not even consider the 4.x versions at all?   I had
the thought in my mind that upgrade 3.30 --> 4.x would be easier step to
take, when considering all the SQL optimizations and table structure
changes etc.

By the way, is there some quick advice or FAQ how to perform those two
upgrade choices, either 3.x --> 4.x or  3.x --> ElevateDb?  
I tried to find with phrases like 'migration path', 'upgrading' but I
did not find it. In general ElevateDB seems to roll everywhere and looks
like most of the 4.x related stuff is almost disappeare.

> http://www.elevatesoft.com/edb_prodinfo.htm

That seems to be a comprehensive list of all the features ElevateDB
offers. Yet I really would want to see _something_ told when comparing
to older DBISAM versions.
Maybe some numbers about the speed enhancements, multitudes of faster
memory FastMM4 management, direct support for multi core CPUs, more
robust database structure, better encrypting, or anything.

> The obvious benefit to using a newer product is that 3.x is no longer
> getting any updates,

Yes, but I don't see these as _benefits_ in general. No great benefit
when there is no problem with the current DBISAM version, as there's no
problem running every day apps on a XP machine. Just by saying that
Vista is newer and heavier operating system and has lots of listed
features when compared to XP/W2k, that still does not convince me, and
make me see a need for an immediate operating system upgrade

Some of the real DBISAM -> ElevateDB upgrade benefits would be those
things I listed above.

---
All right! Now when you told about that possible FastMM4 boost even I
can now see that maybe there would be a good and credible reason to
upgrade.

Those possible upgrade tasks and pains from 3.x --> <something> still
need to be be found out.

Thanks for all the comments given this far!
-Asko S.

Asko

You don't say which version of Delphi you're using. D2006/7 have FastMM built in by default. Earlier versions its a doddle to add.

>> << If someone can give good reasons why that amount of data would run better
>> on DBISAM 4.x or 5.x versions, then we will think about. >>
>>
>> ElevateDB will be better with larger amounts of rows due to its design. You
>> can find out more information on ElevateDB here:

Someone did do some speed tests and they're in the ngs look for Dave Harrison in the binaries.

>Does this mean that your primary suggestion is to go directly from 3.30
>--> ElevateDB? And not even consider the 4.x versions at all? I had
>the thought in my mind that upgrade 3.30 --> 4.x would be easier step to
>take, when considering all the SQL optimizations and table structure
>changes etc.

I'm going V4->ElevateDB and I'd advise you to make the jump rather than take an intermediate step. If you look for my other posts you'll see the sorts of things that have "bitten" me. Once you know what you're doing to solve the issues its not to bad. If you have specific areas of concern why not post them and those of us who are in transition (I doubt there's anyone through it yet) will try and help.

>By the way, is there some quick advice or FAQ how to perform those two
>upgrade choices, either 3.x --> 4.x or 3.x --> ElevateDb?

Good question - No.

>Maybe some numbers about the speed enhancements, multitudes of faster
>memory FastMM4 management, direct support for multi core CPUs, more
>robust database structure, better encrypting, or anything.

Apart from "feeling" faster for queries one area which is of extreme importance to me is that of full text indexing and here I can say that ElevateDB really outperforms DBISAM. I started re-writing an app before ElevateDB so the conversion program was for DBISAM. It took somewhere in the region of 4 hours to run. When I decided to go to ElevateDB I left the majority of the conversion in DBISAM (already written and its stuff I understood) but added in the migration to ElevateDB. Since the way FTI was handled changed I ripped out all but necessary to the conversion indexing and created all of the indices (including the full text ones) in ElevateDB. The time taken has shrunk to c1.5 hours.

>> The obvious benefit to using a newer product is that 3.x is no longer
>> getting any updates,
>
>Yes, but I don't see these as _benefits_ in general. No great benefit
>when there is no problem with the current DBISAM version, as there's no
>problem running every day apps on a XP machine. Just by saying that
>Vista is newer and heavier operating system and has lots of listed
>features when compared to XP/W2k, that still does not convince me, and
>make me see a need for an immediate operating system upgrade

But on that basis there's no point to going to V4 either. Also Vista sucks big time. The main thing the new features in Vista do is give me something to swear at, a fact I can't see changing. ElevateDB has caused me to swear a lot but I positively like a lot of the new features. My problem is I would have liked to keep some of the old ones that have gone.

>All right! Now when you told about that possible FastMM4 boost even I
>can now see that maybe there would be a good and credible reason to
>upgrade.

Unless Tim has done something special in ElevateDB with FastMM I can't see that being relevant. But it might be that ElevateDB takes advantage of it in ways that DBISAM can't.

Roy Lambert

Roy Lambert wrote:
>

> You don't say which version of Delphi you're using. D2006/7 have
> FastMM built in by default. Earlier versions its a doddle to add.

We took a couple of weeks to evaluate D2005 version when it was still a
valid version. Our experience was so bad that we have been avoiding all
D200x versions, and that's why have been stuck to D7 version.

All our development time, year after year, goes just by writing new
code. Fullfilling the never ending demand of new functionalities that
clients keep bringing in. Also DBISAM 3.30 has done it's work and no one
worries about it. That's why also those kind of possible FastMM boost
news have succeeded to bypass our eyes.

> Someone did do some speed tests and they're in the ngs look for Dave Harrison
> in the binaries.

Tip for Elevatesoft: If these tests were good for ElevateDB, then why
not add a link to ElevateDB page that points right to this benchmark.

I'll now have to go and dig that myself from the binaries.

> I'm going V4->ElevateDB and I'd advise you to make the jump rather than take an
> intermediate step.

Well, I'm still waiting if also Tim thinks this is the way to go. Better
take this one 'giant step' instead of taking one extra step in between.

> >By the way, is there some quick advice or FAQ how to perform those two
> >upgrade choices, either 3.x --> 4.x or 3.x --> ElevateDb?
>
> Good question - No.

If some link to that kind of information would appear on Elevate pages
within next 1..2 weeks, I would be very impressed and appreciated.

> Also Vista sucks big time. The main thing the new features in Vista do
> is give me something to swear at, a fact I can't see changing.

Looks like we both have a lot of common opinions and common Windows
operating system version experience on our background

> ElevateDB has caused me to swear a lot but I positively like a lot of
> the new features. My problem is I would have liked to keep some of the
> old ones that have gone.

Currently I have not sweared with 3.30 version for years, a workhorse
has done what has been asked. And refused if it has not had the
functionality (full Client Dataset functionality I think is still
missing) that was wanted. And also the huge size of DBISAM Index Files
makes one to wonder what has actually been stuck in to them.
 
> Unless Tim has done something special in ElevateDB with FastMM I can't
> see that being relevant. But it might be that ElevateDB takes advantage
> of it in ways that DBISAM can't.

Autsch..., one potential ElevateDB upgrader who was almost by 95%
convinced and sold, you just speared him to death.  Hopefully you can
deal this lethal customer stabbing thing between you and Tim

My original thought when Tim told about that FastMM4 was that could it
really be that simple. Just add one new Unit, and all my Delphi apps
will immediately get all the performance boost of multicore CPUs.  

Then I had no ways to argue about anything, without even having FastMM
installed anywhere. But now, is that FastMM4 really a good and known
performance booster for DBISAM/ElevateDB type applications that are run
in Multi-Core CPU machines?

And thanks for all the comments this far.
-Asko S.

Asko

>We took a couple of weeks to evaluate D2005 version when it was still a
>valid version. Our experience was so bad that we have been avoiding all
>D200x versions, and that's why have been stuck to D7 version.

I think D2005 was a major mistake. D2006 doesn't seem to bad. The new layout can take a bit of getting used to but I prefer it now over my old workhorse D6. People's experiences vary wildly some have major headaches for others it just works. I think one of the major areas that affect it are just which 3rd party components are installed.

>Tip for Elevatesoft: If these tests were good for ElevateDB, then why
>not add a link to ElevateDB page that points right to this benchmark.

If you simply judged on the results Dave obtained you'd go back to Paradox

The problem with speed tests is that so often they're not relevant to a specific individual's needs. EG Dave's tests are only about inserting records into a large database. For me one of the main ones is the speed of adding a new record with full text indexing, and deleting the indexed records as well. For others it will be the speed of a query with lots of JOINs.

I'd love to see some speed tests but I'm uncertain as to what would be useful for the majority of users/potential users.

>(full Client Dataset functionality I think is still
>missing) that was wanted.

I think that's made it into ElevateDB

>And also the huge size of DBISAM Index Files
>makes one to wonder what has actually been stuck in to them.

Lots of indices

>Autsch..., one potential ElevateDB upgrader who was almost by 95%
>convinced and sold, you just speared him to death. Hopefully you can
>deal this lethal customer stabbing thing between you and Tim

There are plenty of other reasons to look at ElevateDB apart from handling multicore cpus.

>My original thought when Tim told about that FastMM4 was that could it
>really be that simple. Just add one new Unit, and all my Delphi apps
>will immediately get all the performance boost of multicore CPUs.

From the bit of reading I've done on the subject taking full advantage of multicore/multiple cpus isn't that simple. The OS, compiler and application all need to be written to take advantage of it. I think multi-threading an app will help (the OS can then easily split the app up). But if you think of database operations especially a big long query I think there are engines that will split that up to sun chunks on separate cpus and then stitch the results back into a whole. But I don't think ElevateDB is that clever yet (could be wrong though).

>Then I had no ways to argue about anything, without even having FastMM
>installed anywhere. But now, is that FastMM4 really a good and known
>performance booster for DBISAM/ElevateDB type applications that are run
>in Multi-Core CPU machines?

The old native Borland memory manager wasn't very good and would allow memory to become fragmented, and sometimes not accessible to an app. Tim wrote his own to try and get round the problems but has bowed to the specialist produced FastMM.

Its worth adding in. You'll get a bit extra speed (guaranteed) and a leak detector for your apps, and all it takes is about 2 lines of code per app.

Roy Lambert

Asko,

<< I'll have to check what that FastMM4 will require in general, when
thinking about all the 3rd party components we are using. Or maybe there is
nothing to worry about, just stick the new memory manager in to Delphi? >>

You just stick it into the first line of the USES clause for the dbsrvr.dpr
project file, and re-compile.

<< Does this mean that your primary suggestion is to go directly from
3.30 --> ElevateDB? And not even consider the 4.x versions at all? >>

Yes.

<< I had the thought in my mind that upgrade 3.30 --> 4.x would be easier
step to take, when considering all the SQL optimizations and table structure
changes etc. >>

Yes, but your question was which was better, not which was easier.

<< By the way, is there some quick advice or FAQ how to perform those two
upgrade choices, either 3.x --> 4.x or  3.x --> ElevateDb? >>

You can find out the 4.x --> ElevateDB migration information here in the
manual:

http://www.elevatesoft.com/scripts/manual.dll?action=mancat&id=edb1&product=d&version=7&category=2

Unfortunately, you have to combine the 3.x to 4.x upgrade information with
the 4.x to ElevateDB migration information to get a picture of what is
involved with migrating from 3.x to ElevateDB.  You can find the 4.x upgrade
information here:

http://www.elevatesoft.com/scripts/manual.dll?action=mancat&id=dbisam4&product=d&version=7&category=0

<< Yet I really would want to see _something_ told when comparing to older
DBISAM versions. >>

There's a product comparison with 4.x specifically, and DBISAM in general,
here:

http://www.elevatesoft.com/prodcomp.htm

<< Maybe some numbers about the speed enhancements, multitudes of faster
memory FastMM4 management, direct support for multi core CPUs, more robust
database structure, better encrypting, or anything. >>

We don't issue any specific benchmark numbers due to the inherent issues
with them not being worth squat for a particular situation.

<< Yes, but I don't see these as _benefits_ in general. No great benefit
when there is no problem with the current DBISAM version, as there's no
problem running every day apps on a XP machine. >>

Yes, but there are issues with 3.x on Vista, and the fact that those aren't
fixed is because 3.x hasn't had an update in over 3 years.

<< Some of the real DBISAM -> ElevateDB upgrade benefits would be those
things I listed above. >>

The majority of the benefits are listed in the product information page that
I linked to before.  If you don't see any of those items as benefits or
don't have any customers/users using Vista, then you probably should stay
where you're at.

--
Tim Young
Elevate Software
www.elevatesoft.com

Asko,

<< Tip for Elevatesoft: If these tests were good for ElevateDB, then why not
add a link to ElevateDB page that points right to this benchmark. >>

We do not publish performance benchmarks, per the reasons that I've already
noted.

<< If some link to that kind of information would appear on Elevate pages
within next 1..2 weeks, I would be very
impressed and appreciated. >>

With all due respect, if you had kept up with the upgrades over the years
then it wouldn't be necessary.  We cannot afford to constantly place an
emphasis on customers that don't upgrade over those that do.   That is a
recipe for failure.  The 100% sure-fire way to keep up-to-date with the
products is to purchase and use the major upgrades.

<< And refused if it has not had the functionality (full Client Dataset
functionality I think is still missing) that was wanted. >>

Again, this is because DBISAM 3.x was released near the end of 2001, almost
7 years ago.  We've only been in business for 10 years this August.

<< And also the huge size of DBISAM Index Files makes one to wonder what has
actually been stuck in to them. >>

That's the index statistics, which makes it possible to have things like a
logical record number and accurate cost statistics for the query optimizer.
However, with ElevateDB we have eliminated the index statistics, making the
indexes more compact and efficient without losing the ability of the query
optimizer to make accurate cost estimates.

<< My original thought when Tim told about that FastMM4 was that could it
really be that simple. Just add one new Unit, and all my Delphi apps will
immediately get all the performance boost of multicore CPUs. >>

Yes, it is that simple.

<< Then I had no ways to argue about anything, without even having FastMM
installed anywhere. But now, is that FastMM4 really a good and known
performance booster for DBISAM/ElevateDB type applications that are run in
Multi-Core CPU machines? >>

Yes, it is.  See here on the why:

http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=46974&page=1#msg46974

In that post I'm referring to the DBISAM memory manager (dbisammm.pas),
which is no longer used in favor of the better FastMM4.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:67C371BC-F6DE-4FB1-B6DF-2FC35F07D08A@news.elevatesoft.com...
>
> You just stick it into the first line of the USES clause for the
> dbsrvr.dpr project file, and re-compile.
>

Can you reccomend a good glue to do the sticking bit please.

Rita