Hi all,

I'm been evaluating the ElevateDB trial for two weeks now, with the intention of using it in our next project starting next week.

Some others members of our team are pushing for FireBird which we have used in the past and its worked very well.

Even though I also like Firebird, I also like the level of integration we might achieve with ElevateDB, and some features that are not needed today but is nice to have such as Jobs and Replication.

For those of you that chose ElevateDB over open source databases, would you care to share your reasons and experience?

In our case we're looking for an embedded-able database for a new product developed in Delphi.

Greatly appreciate your comments.

Regards,
Mario

Mario,

Let me mention what I find important:

1) EDB can encrypt the database so end-users won't go in and change things.

2) Tim is coming out with new features several times a year.

3) For queries with a large number of rows, EDB can retrieve only the number of rows necessary to fill the grid. So large queries will have the rows displayed quite quickly without having to wait for all the rows to be retrieved.

4) Excellent support and regular bug fixes.

5) The same program can connect to a local database or server without code changes. Also a program can access the database locally when others are using the same database as C/S.

Barry

Mario


For me the important things were:

1. Native Delphi
2. Full Text Indexing
3. The ability to write my own add in functions
4. The ability to easily subclass and extend the table & query components to remove the annoyances (null <> emptystring, char fields not right trimmed, not truncating fields longer than the defined length)
5. Bloody good support (especially when its my fault/stupidity)

Other things you take for granted in almost any decent DB system

Roy Lambert

Mario

I second all the important things that Roy mentioned. Additionally, one
of the more important things for me are the integrated VCL components.
I don't have to go out and purchase a 3rd party library (i.e., IBDAC or
AnyDAC, which IMHO are excellent components) to be able to access data.

Additionally for me:
1. EDB Manager allows me to connect to data on numerous servers without
having to change server names, etc. I just have to create a new session.
2. The ability to use SQL commands to do virtually anything I need to
do with:
   a. Security
   b. Databases
   c. Tables
   d. Indices
   e. Triggers
   f. Functions
   g. Stores
3. My databases rely heavily on security due to the nature of the work
I do. The ability to define security down to the table level for
multiple user roles is big for me.
4. EDB Stores is a phenomenal concept and it works flawlessly.

Even though Roy mentioned it, I have to double up on his "Bloody good
support" reason. The newsgroups are great and Tim provides phenomenal
support, even when the problem is between you and the keyboard and not
EDB.

--
Jan Ferguson


Mario Enríquez wrote:

> For those of you that chose ElevateDB over open source databases,
> would you care to share your reasons and experience?

J.B.


>Even though Roy mentioned it, I have to double up on his "Bloody good
>support" reason. The newsgroups are great and Tim provides phenomenal
>support, even when the problem is between you and the keyboard and not
>EDB.

and he has yet to tell me I'm stupid (I generally realise it myself though)

Roy

Roy,

I Agree! I don't think Tim would ever say that to a customer (although
maybe he might think it . Most of the time I end up hitting myself
in the forehead and saying..."Duh!"

--
Jan


Roy Lambert wrote:

> and he has yet to tell me I'm stupid (I generally realise it myself
> though)

Mario,

I have used Firebird for a couple of semi-serious projects due to a client requirement. I am biased towards EDB as I use it all the time, however despite my bias I still prefer EDB, if that makes sense. I just feel it is a more focused & better articulated product.

Others have already listed the many really positive reasons to support EDB, such as how customizable it is, replication, encryption etc. For me the overriding thing is that I cannot think of a single time I have had a "gotcha" with EDB. _All_ the features actually work as stated, and the code-design (i.e. Tim's adaptations/extensions of SQL plus how the Delphi components are organised & written) is faultless.

With Firebird you have to use a third party component to access the DB engine/files, whilst many of these are really good (I have used AnyDAC & heard about others) there is still some level of disconnect. Also there are a number of things you just can't easily do with Firebird which are possible with EDB (at least in the Firebird versions I was using).

Finally, EDB feels as though it is in extremely solid development, Tim matches Embaracedro upgrades really well. When I tried to get support for Firebird (just simple "How do I" questions) it was tough, though that might be because I didn't know where to look.

Adam


I've just thought of another one the FM. I don't RTFM very often but its always there and an excellent reference unlike some products I have used (Mr Delphi I'm looking at you amongst others)


Roy Lambert

Thanks everybody for your comments, greatly appreciated!

We're almost sold on ElevateDB by now as we're very impressed with the feature set and also with the reassuring feeling that comes from reading all the positive comments from current customers.

There's a two more remaining questions, that are not specifically related to ElevateDB but any other database product in this same category...

1.How do you deal with the inherent risk associated with investing your development $$ and effort on a close source database product vs a well established open source database (MySql, FireBird, Postgres SQL, etc)? I guess everybody might have a different way to approach this issue, but would be helpful to hear some opinions.

2.And regarding marketability of your product, when a potential customer asks about what's your database backend, doesn't it make the sale a bit harder when you came up with a relative unknown database? What has been your experience on this subject?

Thanks again everybody for your response and time.

Regards,
Mario

>>1.How do you deal with the inherent risk associated with investing your development $$ and effort on a close >>source database product vs a well established open source database (MySql, FireBird, Postgres SQL, etc)? I >>guess everybody might have a different way to approach this issue, but would be helpful to hear some opinions.

I personally think that open / closed source is not the issue here. Sustained development / a living product is what you need. There are plenty of redundant open source components out there!

If you want security & the ability to build from source pay Tim the extra for the source code then you essentially have an "open source" product in the sense that you can continue to build in new versions of any IDE even if Elevate Software was to vanish.

>>2.And regarding marketability of your product, when a potential customer asks about what's your database >>backend, doesn't it make the sale a bit harder when you came up with a relative unknown database? What has >>been your experience on this subject?

Honestly I don't know any customers knowledgeable enough to really say "we want Firebird" & if they do they probably have a really good reason. DB Engines are pretty arcane, and EDB measures up on all the stats such as speed, cost, capability etc. so you can just state the facts ...

I sometimes have customers saying "we want Microsoft" ... I counter them by saying "are there any Microsoft products you like?" and pointing out that each new version of Windows is more messed up than the one before. If that doesn't get them I explain how much more expensive it will be for them to use MSSQL