Hi All,
I'm starting a new project and working through coming to grips with EDB.  I've got 10 years of DBISAM behind me and am very comfortable with it.  Whilst my EDB experience is going OK, and I'm about to post some questions, I have to ask this.

Whats' the advantage of using EDB over DBISAM?

I'm building a desktop application in XE4, only ever to be deployed in English and Australia.  Do I need to spend this time finding my way around EDB?
Thanks in advance,
Bruce.

Bruce

I made the transition from DBISAM to EDB about 7 years ago, so my memory of the whole process is a bit fuzzy.

Some parts of the switch are very easy, others I remember requiring a learning curve.

The Delphi components for both products are similar, but EDB has some extra bells and whistles. I am sure there are recommendations on the newsgroups and even in the on-line Help about differences and migration.

The main gains (for me) relate to:

* EDBs deep support for a complex scripting language which allows many complex operations to be run on the DB rather than in a programme.

* EDBs provision of a wide range of additional tools enabling you to use the added language functionality in new functions, procedures and jobs.

* I don't _think_ DBISAM supports concepts like Calculated fields or Generated fields in the same way that EDB does. These are really powerful, allowing fields in 1 table to be generated from functions which may look up values elsewhere in the DB.

* EDB has Replication, allowing one set of data to be instantiated in more than one location, with scripts to synch data between locations.

* EDB has Triggers, and also fully supports referential integrity through Constraints.

* EDB has a full "Catalog" which holds metadata for items such as Tables, TableColumns etc. in the database. This means you can run scripts which query the structure of the database, and use this in the script. For example you can write a function to iterate through all the tables and update some value ...

Others may add to this list ...

I think that unless your data requirements are fairly simple, I would encourage you to consider EDB, it is a really solid powerful product. You are likely to end up using EDB's "extra" features if you do switch, even if you don't think you need them right now.

I had no real idea why I might want to use Replication when I switched from DBISAM to EDB ... but now I use it in most of my projects and it is really valuable.

Adam

Bruce Rogers wrote:

> Whats' the advantage of using EDB over DBISAM?

I did this transition recently (see my earlier posts when I upgrade a
project), and the simple answer is that there is very little (if any)
downside, and lots of upside. You have to learn the setup, but then you
have a much more powerful SQL engine, and permissions, and all the
modern stuff that brings a lot of power. I'd need a special reason to
be using DBISAM on any new project, and the only reason I have is the
ability to wipe a table file and have it auto-rebuilt without fuss, and
that's not really a good thing for most situations! I also think it can
be done in ElevateDB now too, though again not recommended. (It says a
lot that support people for one of my applications had a tendency to
just blat files to solve problems...)

Go with it, you'll like it.

--

Matthew Jones

Bruce


>I'm building a desktop application in XE4, only ever to be deployed in English and Australia. Do I need to spend this time finding my way around EDB?

Ignoring my first reaction which was "you've bought it so you might as well use it" the genuine answer is "it really depends"

1. DBISAM is in maintenance mode. That doesn't mean it won't get any new features or  that its about to disappear

2. Speedwise ElevateDB scores over DBISAM in full text indexing apart from that in some areas DBISAM is faster, in others ElevateDB

3. SQL is much more powerful in ElevateDB. If you don't use SQL much this isn't a benefit but it does give you a lot more capability if you start to make the switch

4. ElevateDB can be enhanced with external functions far more easily than DBISAM and they bolt into the database manager unlike DBISAM. This was quite a big benefit to me since I had a number of customisations especially in full text indexing

5. ElevateDB is somewhat more difficult to manage since you can no longer just copy tables around, but there are ways to accomplish the same result

6. ElevateDB is catalog based - sometimes I think that's good, sometimes bad - mainly good since it stores all the structure information in one place and you can access / handle it easily - eg list of tables or columns takes one simple bit of SQL

7. All table management is now SQL based - bit of a culture shock if you're not used to it. I'd been switching over to use SQL for table management whilst using DBISAM since its simpler than table methods

8. Column types - good selection and the addition of COMPUTED & GENERATED.

9. Date arithmetic in SQL&  INTERVALs - I suggest getting a bottle of a good single malt before venturing there.

Overall summary: both DBISAM and ElevateDB are good solid databases. ElevateDB is based on the SQL (2004 I think) standard and if you start using it gives you a good introduction to other implementations. The transition is a lot easier now there are more people to answer questions (I was an early adopter and it was mainly Tim who could provide answers). If you use mainly table navigation the transition will be easier than if you have heavy SQL use.

Is it worth making the move - on balance - probably but as I said above "it really depends"

Roy Lambert

Matthew


>I did this transition recently (see my earlier posts when I upgrade a
>project), and the simple answer is that there is very little (if any)
>downside, and lots of upside. You have to learn the setup, but then you
>have a much more powerful SQL engine, and permissions, and all the
>modern stuff that brings a lot of power. I'd need a special reason to
>be using DBISAM on any new project, and the only reason I have is the
>ability to wipe a table file and have it auto-rebuilt without fuss, and
>that's not really a good thing for most situations! I also think it can
>be done in ElevateDB now too, though again not recommended. (It says a
>lot that support people for one of my applications had a tendency to
>just blat files to solve problems...)

That baffles me -in  ElevateDB if you delete the table its automatically recreated when you try and use it - built in - it just accesses the catalog for the rebuild information. How does DBISAM do it since the table is the thing that hold the "catalog"

Roy Lambert

Bruce


I've just thought of a really easy way to make the decision:

if this is the last project you're likely to use either DBISAM or ElevateDB on then stick with DBISAM, if you're going to be in the same position of making a choice in the future go with ElevateDB.

Roy Lambert

Roy Lambert wrote:

> That baffles me -in  ElevateDB if you delete the table its
> automatically recreated when you try and use it - built in - it just
> accesses the catalog for the rebuild information. How does DBISAM do
> it since the table is the thing that hold the "catalog"

Hmm, that's possible completely handy in ElevateDB, or terrible, since
you could lose a lot of data and not know. But DBISAM has nothing, but
you can easily code it to say "if table MyTable doesn't exist, then
create table with these fields etc". Just Delphi not SQL, but easy to
do.

--

Matthew Jones

Bruce,

<< Whats' the advantage of using EDB over DBISAM? >>

I'm going to answer a question with a question:  how much data, and how many concurrent users ?  One of the EDB's main improvements is in performance with large tables, with better concurrency as a result.

The other main improvements that apply to you are:

SQL: EDB has a way more complete SQL (2003) implementation

Client-side options:  EDB has an ODBC driver, .NET data provider, and PHP extension.

EDB Manager: a lot of improvements over the Database System Utility.

There's a complete comparison here:

http://www.elevatesoft.com/products

(at the bottom)

I apparently need to add the PHP extension to that comparison list.

Tim Young
Elevate Software
www.elevatesoft.com

Tim


>I'm going to answer a question with a question: how much data, and how many concurrent users ? One of the EDB's main improvements is in performance with large tables, with better concurrency as a result.

What's a large table? Are we talking 10k rows, 100k, 1m or what?

The other thing that occurs to me now is what's the c/s performance comparison? I know you don't like speed comparisons but do you have any idea?

>
>EDB Manager: a lot of improvements over the Database System Utility.

Being wicked - a number of them not readily visible but VERY useful once you've found them.

That's made me think - I'm going to start a thread about it!

Roy

Thanks everyone.  

I appreciate the quantity and quality of the answers, clearly "Bite the bullet and get on with EDB".

Bruce.