Michael,

<< Well, as i can see bulk adding records to EDB slows as DBISAM did ... >>

Not nearly as much.  You have to get up around 1 million rows before you
start to see a significant slowdown.

<< Now, i don't have 500 thousand records to test but i might have within
2010 ... >>

Try this benchmark:

http://www.elevatesoft.com/newsgrp?action=searchopenmsg&group=13&msg=1556&keywords=benchmark*#msg1556

ElevateDB has gone from being behind DBISAM by about 2000 rows/second to
ahead by 2000 rows/second.  In the past year I've updated the ElevateDB
buffer manager, Win32 (not .Net) string processing/comparisons, the
filter/join processing, and several other key areas in order to improve
performance.

<< Yes, but it doesn't have the "easy of use" of DBISAM had ... So it still
lacks of some pretty handy DBISAM functionality. >>

Such as ?

<< Of course ... But since your majority of your customers are coming from
DBISAM, you should make the things more "compatible". >>

They're not *supposed* to be compatible.  Many of the things about DBISAM
that are "convenient" also make it unable to handle things like foreign-key
constraints and easier handling of metadata across all types of client
applications.

<< Eg, in DBISAM i could alter a field name and it altered the index. In EDB
i must first remove the index and then Alter field and
readd the index. >>

That's a bug, and if you would have reported it, it would have already been
fixed, just like it will now be fixed.

<< Why do you think that many of your customers decided not to move to EDB
yet ? ... >>

What makes you think that the customers that haven't moved to EDB are doing
so because they don't like EDB ?  For many, their applications are legacy
applications that aren't up for a rewrite or update yet, and they're staying
with what they've got because they've got a lot of money invested in it.  We
don't care either way - we want them to use what will make them money.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Roy,

> In my view its only in the many apps with many users accessing 1 database case where
> the optimum is storing the logic in the database. At the other end of the spectrum, 1 app
> with 1 user accessing 1 database, the optimum is all logic in the program. In between it
> gets fuzzy, some stuff is better in the database, some in the program.

I agree. That's why I now tend to use DBISAM for smaller or single user applications, and ElevateDB for larger multi-user systems.  Not that you can't use
either of them the other way around, it's just that I think ElevateDB is ideal for large network applications.


> But I must take exception with your use of the word "intelligence" in relation to government IT.

Ahh, notice I said that the intelligence is built into the "database".  I said nothing about anyone who works there (including me).

Regards,

Steve

Dear Tim,

> << Well, as i can see bulk adding records to EDB slows as DBISAM did ... >>
>
> Not nearly as much.  You have to get up around 1 million rows before you
> start to see a significant slowdown.

Well i tried a couple thousand records ... and i notice a small slowdown
from the 1000 and up.

> << Now, i don't have 500 thousand records to test but i might have within
> 2010 ... >>
>
> Try this benchmark:
>
> http://www.elevatesoft.com/newsgrp?action=searchopenmsg&group=13&msg=1556&keywords=benchmark*#msg1556

Sorry, no time for benchmark now

> ElevateDB has gone from being behind DBISAM by about 2000 rows/second to
> ahead by 2000 rows/second.  In the past year I've updated the ElevateDB
> buffer manager, Win32 (not .Net) string processing/comparisons, the
> filter/join processing, and several other key areas in order to improve
> performance.

I'll see if i can do my own benchmark in the future ...

> << Yes, but it doesn't have the "easy of use" of DBISAM had ... So it still
> lacks of some pretty handy DBISAM functionality. >>
>
> Such as ?

For example, Repair/Optimize all the tables within DBISAM Manager,
it didn't have a catalog so it was easier to make it more portable.

> << Of course ... But since your majority of your customers are coming from
> DBISAM, you should make the things more "compatible". >>
>
> They're not *supposed* to be compatible.  Many of the things about DBISAM
> that are "convenient" also make it unable to handle things like foreign-key
> constraints and easier handling of metadata across all types of client
> applications.

I got that

> << Eg, in DBISAM i could alter a field name and it altered the index. In EDB
> i must first remove the index and then Alter field and
> readd the index. >>
>
> That's a bug, and if you would have reported it, it would have already been
> fixed, just like it will now be fixed.

For crying out loud and i thought it was by design!
The same goes for primary/foreign keys too ...

> << Why do you think that many of your customers decided not to move to EDB
> yet ? ... >>
>
> What makes you think that the customers that haven't moved to EDB are doing
> so because they don't like EDB ?  For many, their applications are legacy
> applications that aren't up for a rewrite or update yet, and they're staying
> with what they've got because they've got a lot of money invested in it.  We
> don't care either way - we want them to use what will make them money.

Ok, i can understand this ...

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Dear Roy,

> One thing to remember is that ElevateDB is NOT an upgrade to
> DBISAM but a totally different product. Its why Tim was (relatively)
> easily persuaded to continue DBISAM.

Well, that's the point from what i got ... I have to get used to it.

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Dear Tim,
  Anyhow, my point was to make an easy way to convert
  a non-encrypted database to encrypted without doing
  all this stuff. Maybe you can add the code to convert
  it from EDB Manager. (So EDB Manager will do all these
  steps for us, just asking for a password only)

I guess this will be in your wish list ?

Thank you

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Michael,

<< I guess this will be in your wish list ? >>

Yes, it is on the list.

--
Tim Young
Elevate Software
www.elevatesoft.com