Database connectivity Delphi

Question

I'm using delphi for years, but never for database stuff, but recently started researching and testing.

I must say, i'm impressed, most of things happens automatically, i'm used to write by hand in php and python.

i'm going to develop a commercial system for a friend, (2 layers) 5 user computers, 1 database server.

Database server will be a decent machine with (raid-1) 2 hard drives running (MySql5.1 or Postgre or Firebird, open to suggestions).

ADO

• Easy to use
• Easy deployment (only mysqlconnector installer)
• The slower?

DbExpress

• Need to ship 4 files [dbxconnections.ini, dbxdrivers.ini, mysqldll, driverdll]
• The more complex (harder to use)
• ClientDataSet add complexity, but looks really useful
• No free Postgre driver?

Zeos

• Easy deployment (1 dll)
• Easy to use

As you can see the desired features are:

• fast
• easy to use
• easy to deploy

I can't test all in a real scenario (clients, server), so i hope that you guys with experience can help me out in which one to choose and why.

EDIT: Thanks everyone, i think i will go with ADO (probably) or Zeos

Thanks in advance
Arthur

Homosexuality

there is no need to redistribute dbxconnections.ini and dbxdrivers.ini in recent versions of Delphi. With dbexpress you don't need to register any dll only need to put it in the same folder. – Capuano

Answer 1

I have worked on many commercial high volume systems using ADO without any problems. Deployment is relatively simple since its included in the OS. Since it has such a wide audience, most of the major issues have been identified and corrected. Getting help with ADO connectivity is very easy. The database support is very deep (connectionstrings.com) which make supporting additional database engines almost trivial (you may need to still install the client drivers, but that would be the same for almost any solution).

Performance isn't much of an issue, it really will come down to database architecture and engine selection.

Aquifer

Thanks, any suggestions on the database engine? – Homosexuality

I'd stay away from ADO if you ever intend to go cross-platform (of course, this assumes that some day Delphi will itself be cross platform). – Helicline

We should not expect Delphi to be cross platform soon. – Homosexuality

For engine slection: SQL Server, SQL Server express scales well. Access also works well for lower user counts, just remember that with Access there is no server piece so all data will come down the wire for any queries which result in a table scan. – Aquifer

@Homosexuality Cross platform delphi is cooking. With dbxpress you can run your apps in linux now with Wine. – Capuano

Apart from Delphi having become more or less cross-platform, Lazarus/FPC already is. From a portability perspective, Zeos might make sense. – Brindled

@reiniero: Or even Sqlite if your interested in portability. When I answered this question over 2 years ago, I was referencing the information that was readily available at the time for Delphi. – Aquifer

Answer 2

@arthurprs, for you scenario

(2 layers) 5 user computers, 1 > database server.

alt text http://www.techsolusa.com/images/firebird-logo-64.gif The Firebird RDBMS is a very good option , because is very stable, fast, runs on Linux, Windows, and a variety of Unix platforms and meet with you requirements.

alt text http://d.yimg.com/kq/groups/12858579/homepage/name/homepage.jpg Respect to the components for connection i go for ZEOS.

I have used this combination in many small and medium projects, with excellent results.

Tadzhik

+1 Thanks for everybody who mentioned ZEOS Lib I had not heard of it. I do wonder WHY isn't the delphi 2010 rev out yet (v7)? – Helicline

Zeos looks good and simple and it's faster than ADO, i may decide to use it at some moment. Regarding Firebird, i never used it, how it's compared to other database engines? – Homosexuality

@arthurprs: Firebird is the open source derivative of Interbase. Check out the site firebirdsql.org or ibphoenix.com for more information about it. I use it myself for an alternative to products like Interbase, SQLServer, Access and MySQL. I have used all of the above but for my own use and that of my clients I will generally recommend FB first and others second. – Columbic

if you are looking for commercial component use fibplus. – Mossgrown

Answer 3

id have to say im rather happy with NexusDB but the cost for the client/server versions might not be worth it.

it works client/server or fully embedded, simple enough you can have both in your app and switch between them, depending on your clients needs

• the embedded DB is free,
• client/server "Priced per developer" is AU$ 500
• No cost per install.

Oh yeh and its written in delphi ;)

Goldplate

An ERP system I wrote using NexusDB and kbmMW a couple of years ago has been running non stop at a clients. 5 Concurrent local users and up to 50 remote users at the same time with no issues - I'd recommend NexusDB too. – Foxed

Unfortunately i can't afford any paid components, but it definitively looks good. – Homosexuality

Answer 4

I'd say to go with Firebird - is the most used database engine in the Delphi land (see here). For connectivity perhaps is better to go with Zeos (free) or DBX (if you can afford the Architect version - the only one who has the Firebird driver in it).

About ADO: Mature connectivity layer but it will be (forever - most probably) tied to Windows while Delphi will go cross-platform. Also, yes, it tend to be the slower one because of many reasons, including the ODBC drivers which are used in certain situations. But in your case, of course, as skamradt says, I don't think that it will matter so much.

Jezreel

Answer 5

Although I have read people not liking the idea of mixing the two, I have had good results using ADO Datasets as a "provider layer" which then feeds the data into TClientDataSets - so there's no reason you can't use ClientDataSets if you go down the ADO route if you find you need them (and they are useful).

Otherwise, I would echo the comment that ADO is a tried, trusted mechanism that isn't going anywhere. I've always found it more than fast enough. And configuration using UDL files is nice and easy.

Nansen

Answer 6

• dbGo (ADO) is more simple to manage, more universal, more slow
• dbExpress is more fast, more complex to manage, supports less DBMS's
• ZeosDBO is simple to manage, universal like dbExp, slow like dbGo, cross-platform, has few additional components, all sources are accessible

There are few other libraries, resolving all above doubts, although all of them are commercial products. But there I am biased :)

Algol

Answer 7

We have used postgreSQL using Devart pg components with great success in medium sized database apps. We did some limited benchmarking with this combination and found it 2-3 x the speed of using ADO etc.

Eroticism

Answer 8

-- Data access components

I too favour the combination of TClientDataset and ADO. Had worked with it in past and I can say it's trustful. The flexibility of TClientDataset is a big gain. DBExpress is good too. Actually, I use clientdatasets with pretty much any data access layer that have an TDataset descendant...

-- Server

Firebird. Free and easily usable from OLEDB (I used with ODBC) and DBExpress (D2010+ have native DBX driver) - don't know ZEOS, but I believe that it also connect to FB. Scale well to many connections and big databases. There are databases on Firebird with 500Gb and many users reported.

Arezzo