views:

653

answers:

3

When looking for which version of Delphi 2010 to buy, we found the following limitation on the professional one:

Delphi 2010 Professional is designed for developers building high-performance desktop GUI and touch-screen applications with (or without) embedded and local database persistence.

What does this really mean? Does this mean that we'll only face this restriction if we choose to use the native vcl components for database access we'll face this restriction.

And what if we choose to use ADO components instead of those? In this case, how can Delphi avoid us to access remote database servers? Did anyone here ever tried this?

Going even further: if we choose to use a database like Firebird, which is just one file, and used a network mapped drive. Could we be facing the same limitation?

Supposing we opt for ADO, what will be the main consequences?

+1  A: 

Does this mean that we'll only face this restriction if we choose to use the native vcl components for database access we'll face this restriction.

Yes. The professional version simply leaves out some of the driver & driver technology that natively supports certain databases. It still includes ADO support and there are plenty of third-party drivers that you can use to access other databases.

Delphi 2010 does not include any technology to stop you from building applications that interact with remote databases aside from the fact that it does not include DB Express (its own database driver technology).

Larry Lustig
And how compatible is it with the 7 version? Does those ADO components still work with 2010?
Kico Lobo
There is a native set of Delphi components (called dbGo) in Delphi 2010. Not sure when they were introduced. I use them for MS Access, in that context they work fine.
Larry Lustig
@Larry Lustig - ADO Express was introduced in Delphi 5 and was renamed to dbGo in Delphi 6. Some kind of trademark issue.
Bruce McGee
+3  A: 

As I understand it, they're referring specifically about dbExpress and doesn't restrict you from using dbGo or some third party library to access remote databases.

Bruce McGee
Correct. For unknown and (IMHO stupid, given the alternatives below) marketing reasons the Pro ships with dbExpress drivers that can only connect to localhost. Only the driver is limited - nothing else.You can 1) Use third party drivers without this limitation 2) Use ADO/ODBC 3) Use third party libraries like Direct Oracle Access, ODAC, Zeos, IBO, etc. etc.
ldsandon
Agreed. I think database functionality should be less restrictive.
Bruce McGee
+1  A: 

DataSnap is not included in the Pro version either. I got quite interested at a recent Delphi workshop when they showed off DataSnap only to discover when I got back that it's missing from the Pro version.

So I'm back to sticking with my SDAC components and other third party middleware components. Works perfectly without the expense of the enterprise version.

The SQL Server dbExpress driver isn't included (amongst others) but the ADO/dbGo stuff seems to work just fine over the network. But we haven't used the Delphi supplied DB drivers since Delphi 3 due to them keep changing their mind about the latest silver bullet for DB access (much like MS do/did).

shunty
I think it's reasonable to have multi-tier features in Enterprise and above. The database limitation seems to be a little more arbitrary.
Bruce McGee
Reasonable maybe - I'm undecided. Just wish I'd realised before planning my next world dominating datasnap app :-)
shunty
@shunty: Embarcadero always publishes the latest feature matrix, which lets you know what is available in each SKU. http://embarcadero.com/products/delphi/Delphi-Feature-Matrix.pdf
Bruce McGee
Yeah, I know that. And I read it /after/ I couldn't find any datasnap components in my copy of Delphi! I was just disappointed 'cos it was the best bit of the workshop. So I thought it worth pointing out in the context of this question.
shunty