What’s New?
Michael Swindell just came in my office and asked me to blog on what we are cooking up in the database side of the Delphi house. I’m pretty busy right now, so I’m just going to rattle off some things that I hope developers will find interesting. Excuse me if I ramble, I’m not going to spend a lot of time editing this.
I am not new to database technology, Borland or CodeGear, but I am relatively new to Delphi. I joined the team last May. Coming into this team I was fully aware of the proud Delphi heritage as tool for rapidly building database applications. No question about it, this continues to be a key strength of the Delphi product. However over time, several database related technologies have been introduced that either need modernization or provide redundant solutions to our customers. Our customers need cutting edge technology, innovation, and consolidation of our technology offerings with as much backward compatibility and ease of migration as possible. That’s a mouthful and an ambitious goal. However we have a strong development team in place and with ongoing involvement of the Delphi developer community, I think we can pull it off.
Delphi the Super Platform
I think when the .net framework first came out, many people thought it would replace most interest in developing native applications. This thinking proved to be wrong. Hindsight is 20-20 though. We have customers that develop both native and managed applications. We do not want to treat either as second class. Luckily Delphi is the only language and runtime that I know of that allows software to be developed for both native and managed applications in a “first class” fashion. There are ways to compile both .net and java applications into native executables, but they are just bringing their managed runtime into the app as a separate subsystem. To me this is not first class. Delphi on the other hand is more of a proper managed app when executing under .net and a proper native app when executing under the native win32 platform. For example, Delphi will use .net memory management when executing on the .net platform and Delphi will use the existing highly optimized native memory management when executing on the win32 platform. To me this an important feature that makes Delphi a “super platform”. Microsoft with enormous R&D resources could not achieve this kind of cross platform support for VB. Delphi just turns out to be better suited as a super platform.
The new software we are writing is single sourced. We compile the same source code for both win32 and .net. We build and run our dunit test suites every day for both win32 and .net. It works well and allows us to provide a “first class” feature set for both our win32 and .net customers.
Technology Consolidation
Delphi has some redundant database related technologies. Sometimes we will try to consolidate these offerings. This allows us to put more energy into a common solution and simplify the choices for our customers.
When I started last May we had two database SQL connectivity technologies: dbExpress and BDP. Delphi provides 8 dbExpress drivers and 8 or so BDP drivers out of the box. The internals of the dbExpress and BDP actually share a common heritage. They were both created by the same developers, but they are entirely separate code bases. This is a lot of drivers to enhance and maintain. Early on I made the call to consolidate these two technologies into one. The result is the dbExpress 4 framework that will be included in the next Delphi result. The dbExpress framework is written in 100% Delphi. This replaces the com based dbExpress 3 framework. The dbExpress 4 framework is single sourced so applications that use the dbExpress framework can be compiled for both win32 and the .net platform without any source code modification.
So what about BDP? It provides our customers with an ADO.NET solution. However BDP is based on an older “interface” based version of ADO.NET. The newer ADO.NET 2.0 introduced an interface based on abstract base classes and deprecated the more brittle interface based solution. In my opinion, implementations of the ADO.NET abstract classes should not add methods to their implementations to add features. This is Microsoft’s name space. However, I want us to be able to innovate in our connectivity solution. This is why I decided that we should create a “bridge” from ADO.NET to our new dbExpress Drivers and not “extend” the ADO.NET classes. This allows us to move forward on our dbExpress technology and use a very lightweight bridge to provide a single ADO.NET driver. In many ways the dbExpress 4 driver framework is a superset of the ADO.NET technology.
The end result is that we have cut the drivers we must enhance and maintain in half, all driver features are provided to both native and managed applications, and we have an ADO.NET 2.0 driver that bridges to any dbExpress driver. BDP and its support for the older version of ADO.NET 1.1 will be replaced with a new ADO to dbExpress bridge This bridge is implemented using the newer ADO.NET 2.0 abstract base classes.
Product Innovation
We have several innovative technologies in the works. I’d like to talk about some interesting driver extensibility features that came out of our work to consolidate the dbExpress and BDP driver solutions. The new dbExpress 4 framework introduces “delegate drivers”. Delegate drivers are light weight and can be used to provide both pre and post processing of all public methods and properties of the dbExpress 4 framework. There is a single connection property used to place a delegate driver in front of a regular dbExpress driver. Here is a snippet below from my dbxconnections.ini file:
[IBCONNECTION]
DelegateConnection=DBXTraceConnection
DriverName=Interbase
Database=workerbee:c:\BorlandInterbaseexamplesdatabaseemployee.gdb
…
The first line indicates that when we connect to IBCCONNECTION, it will be delegated to by the DBXTraceConnection. DBXTraceConnection has properties in the same dbxconnections.ini file. So its treated very similar to a full fledged driver. Earlier in the same dbxconnections.ini file there is an entry for DBXTraceConnection as well:
[DBXTraceConnection]
DriverName=DBXTrace
;TraceFile=c:\tempdbxtrace.txt
TraceFlags=PARAMETER;ERROR;EXECUTE;COMMAND;CONNECT;TRANSACT;BLOB;MISC;VENDOR;READER;DRIVER_LOAD;METADATA
;TraceDriver=true
;TraceFlags=NONE
You can also chain delegate drivers. For example, you can have a connection pool delegate that delegates to a trace delegate which in turn delegates to an Interbase driver. We will included full source code for two dbExpress delegate drivers: TDBXTrace and TDBXPool. TDBXTrace provides framework level tracing. The output is kind interesting. Instead of “binding” this or “describing” that (who understands that stuff any way?), it outputs Delphi code that indicates how the framework is being used. Here is a snippet from the execution of one of our dunit tests:
{CONNECT } Connection2.Open;
{COMMAND } Command2_1 := Connection2.CreateCommand;
{COMMAND } Command2_1.CommandType := Dbx.SQL;
{COMMAND } Command2_1.Text := ‘SELECT * FROM BASICDML order by F_VARCHAR’;
{PREPARE } Command2_1.Prepare;
{COMMAND } Reader2_1_1 := Command2_1.ExecuteQuery;
{COMMAND } Command2_2 := Connection2.CreateCommand;
{COMMAND } Command2_2.CommandType := Dbx.MetaData;
{COMMAND } Command2_2.Text := ‘GetIndexes "workerbee:c:\BorlandInterbaseexamplesdatabaseemployee.gdb"."sysdba"."BASICDML" ‘;
{COMMAND } Reader2_2_1 := Command2_2.ExecuteQuery;
{COMMAND } FreeAndNil(Command2_2);
So if you are a database developer most of this is going to be much easier to understand than typical database client library trace output. It shows exactly what is being called in the dbExpress framework. You can also enable lower level client library logging as well (this is what dbExpress 3 provided), but I have it disabled in this snippet. The comment in the front of each line shows the trace category. “Connection2” means that this was the second connection created since logging was started. “Commnad2_1” means that this was created by connection 2 and that it was the first connection created by connection 2. Reader has three numbers and as you can probably guessed, this indicates that it is the first reader created by the first command of the second connection. This numbering scheme is especially useful for multi-threaded logging.
Take note of the line that sets Command2_2.Text to ‘GetIndexes’. This demonstrates another innovative feature of dbExpress that I call “extended commands”. Metadata requests pass parameters (i.e. catalog, schema, table pattern), and return a Reader. Sounds like a command, so why not make them the same? To support this, a command type property was added so that the driver knows this a metadata command, not a sql statement or stored procedure. The command type is a string that enables us and other driver vendors to provide new name spaces for commands.
TDBXPool provides basic connection pooling for all dbExpress drivers. This delegate driver also implemented its own extended command that returns a reader with a row for each connection pool that is currently active.
The combination of delegate drivers and extended commands makes for a very extensible driver framework. Delegate drivers are trivial to write. If you don’t like my connection pool or my tracing, it won’t be hard to replace them. Or maybe you can improve them and give them back.
Ok, I better wrap things up now. We have a lot more in the works for this year that I don’t want to talk about just yet. Today I mostly touched on database connectivity. However, this is not the only alligator we are wrestling with. Tooling, runtime components, multi-tier development and core database technology itself are all in the works or at least on the radar. We also fixed some really old bugs this year. We have a great development and QA team skilled at creating highly leveraged solutions. I have met many Delphi developers that are very intelligent, highly skilled, and passionate about Delphi. Delphi developers also tend to be incredibly savvy about building database applications. I am counting on the Delphi developer community to constantly be looking closely at we are doing and provide the kind of feedback that will make Delphi database technology the best it can be. The end result will be much better if we have lots of bright minds critiquing and extending the technology. To that end we will try to continue offering open solutions with source code included when ever possible.
-Steve
Share This | Email this page to a friend
Posted by Steve Shaughnessy on February 16th, 2007 under Uncategorized |
RSS Feed
February 16th, 2007 at 10:05 pm
That sounds pretty freakin’ cool!
Ryan
February 16th, 2007 at 10:52 pm
"BDP and its support for the older version of ADO.NET 1.1 will be replaced with a new ADO to dbExpress bridge This bridge is implemented using the newer ADO.NET 2.0 abstract base classes."
This is, imho, a no-no.
You’d be better to leave the BDP *interfaces* in place and then use the lightweight bridge to DBExpress drivers as implementation. This is, imho, the way to pursue. This would have two advantages:
1) You still have backwards compatibility
2) You make it easy to use the bridge
I think you should be considering it.
My 2c,
Andrew
February 17th, 2007 at 3:25 am
Let me suggest that CodeGear should officially support Firebird, either as a separated driver or even with the InterBase driver. A huge percent of the Delphi community are Firebird users and are claiming for this.
February 17th, 2007 at 4:43 am
Please, support Firebird.
Every Delphi Coder I know is waiting for this.
Me too.
BTW, very interesting ideas you are saying!
February 17th, 2007 at 5:43 am
How hard will it be for 3rd party Delphi DB vendors to build & offer an ECO driver for their own database product?
February 17th, 2007 at 11:02 am
Suport Firebird is a MUST.
Thanks for the work.
February 17th, 2007 at 1:35 pm
Steve,
Please don’t forget about PostgreSQL for this new framework, it’s the best open source database available and is rising very fast in popularity. By having a PostgreSQL driver you also will be supporting EnterpriseDB a very nice database with Oracle compatibility that is built from PostgreSQL and maintains 100% backwards compatibility with PostgreSQL.
Thanks,
Tony Caduto
AM Software Design
Home of Lightning Admin for PostgreSQL and MySQL
http://www.amsoftwaredesign.com
February 17th, 2007 at 2:48 pm
Please, support Firebird.
February 17th, 2007 at 2:49 pm
Text is too wide for 1024×768. Even when scrolling as far left as the right margin allows.
February 17th, 2007 at 2:56 pm
Just a little FYI,
there are close to 275,000 downloads of PostgreSQL for win32, now of course that does not equate to the actually number being used, but it does indicate a large and growing user base on win32, the number for the Unix/Linux platform is much much higher than that as PostgreSQL is included in many Linux and BSD distributions, not to mention Solaris 10.
February 18th, 2007 at 2:29 am
Another vote here for PostgreSQL support.
February 18th, 2007 at 2:53 am
Please support Firebird! Thanks!
February 18th, 2007 at 12:07 pm
That all sounds very promising.
Regarding multi-tier capability a feature that I think would be very useful and an advantage over the competition is being able to write a delphi win32 server and a .net client or vice versa without a 3rd party plug in.
Future DBExpress Examples
PDA or Smartphone running a .Net client working with a Delphi win32 server.
Win32 Delphi rich client working with a Delphi/C# .net server.
Best regards,
Paul
February 18th, 2007 at 1:03 pm
I’d like to see PostgreSQL support also: it’s a fantastic database, very standards-compliant and with a rich feature set, and rock solid.
February 19th, 2007 at 2:21 am
It’s great to see some good decisions being made at CodeGear. I was hoping for some more innovative technology, perhaps object-to-relational mapping, etc. Delphi has always made the simple database app very easy, but when trying to put your business logic in a middle tier, the programming can get tedious.
…Michael…
February 19th, 2007 at 2:21 am
It’s great to see some good decisions being made at CodeGear. I was hoping for some more innovative technology, perhaps object-to-relational mapping, etc. Delphi has always made the simple database app very easy, but when trying to put your business logic in a middle tier, the programming can get tedious.
…Michael…
February 19th, 2007 at 5:55 am
Really good, but still missing a Firebird driver.
February 19th, 2007 at 6:33 am
I would also like to state my support for PostgreSQL support to be included.
February 19th, 2007 at 7:18 am
Another vote here for PostgreSQL support.
February 19th, 2007 at 11:49 am
Thus we will have a wholly new codebase.
Do you know that it means to *retest* whole applications? Nice to know that some old bugs are fixed, but what about new ones? <g> Database connectivity was a Delphi gem, but since dbExpress was introduced to replace BDE that gem did not shine anymore - hope this times these new drivers underwent a proper QA. This is a touchy area - bugs could have devastating effects.
Could you publish some benchmarks about previous and current drivers? I am afraid sharing the same code between native and .NET compiler will hinder some optimizations - and the native Delphi compiler and RTL are not very optimized for actual CPUs - unless the version you are using solved this long-standing issue. Not that the previous drivers were so good - why COM??? - but I’d rely more on C++ and its RTL for small and fast applications like drivers.
February 19th, 2007 at 1:27 pm
Luigi D. Sandon,
I view the DBX 4 improvements as more evolutionary than revolutionary. DBX4 makes it possible to develop drivers in Delphi or C++. The VCL now interfaces with the DBX4 "Delphi" framework. So now the VCL does not care what the driver is written in. One flaver of DBX4 driver is what I call a "dynalink" driver. These are native drivers that are implemented in dlls, not delphi packages. DBX4 supports all dbExpress 4 and dbExpress 3 dynalink drivers. We will be shipping the 8 dynalink drivers written in c/c++ that also shipped in the last release of BDS. We have applied bug fixes and enabled 3 more of them for Unicode. We are leveraging a lot of existing code.
Quality. We have amassed automated dunit tests that we run everytime we check a change into version control. The tests are run against both managed and native. We have enabled the debug modes of FastMM for our dunit tests to quickly detect memory management issues. Every bug we fix is required to have an automated regression test. Will we find all the bugs? No. However, we do try to follow good practices.
Performance. Preliminary internal benchmarks show DBX 4 to be faster that DBX 3 on both native and managed platforms. On managed platforms the diference is much more dramatic. I think the Delphi language has comparable performance to c/c++. If there is a problem in the rtl, then we should fix it. Fastcode group has made many contributions to optimize the Delphi rtl. The more common reason to write drivers in c/c++ is that the driver vendors typically deliver client library header files in c/c++. However, these can often be easily translated to Delphi.
February 19th, 2007 at 1:35 pm
Andrea Raimondi,
A couple comments on BDP:
1) BDP is deprecated, but will be included in the next release of Delphi.
2) BDP implements the ADO 1.1 interfaces. ADO.NET 2.0 drivers also implement the ADO 1.1 interfaces. However these interfaces are deprecated and these interfaces will not be updated for new ADO.NET features.
3) Because ADO.NET 2 and BDP both implement ADO.NET 1.1 interfaces, there is a lot of existing compatibility. In fact John Kaster converted an internal BDP application to use ADO.NET 2 in about 2 hours. I’m sure this will not be the same case for all developers, but it is an interesting data point that indicates there is significant compatibility between BDP and ADO.NET 2.0
-Steve
February 19th, 2007 at 1:44 pm
Firebird and PostgreSQL developers,
I hear you. However, I am not in the position to say when or if we will provide these drivers. However as with the connectivity solutions that proceeded dbx4, this is an open architecture. We provide the source code to the framework. We are already answering questions to driver implementers on our private field test. If people in the open source community would like to develop such drivers, we’ll help them. There is definitely less work to a dbExpress 4 driver than there is for JDBC or ADO.NET.
-Steve
February 19th, 2007 at 1:50 pm
Firebird and PostgreSQL developers,
And one more thing…
Our QA group has a CTS (certification test suite) in the works for dbExpress 4 that will be included in the product as a sample. This is an interface compliance test that will help validate that a dbExpress 4 driver implements the interface properly.
-Steve
February 19th, 2007 at 1:52 pm
Paul Hectors,
I agree with much of what you suggest.
-Steve
February 19th, 2007 at 1:53 pm
Michael Silver,
Have you worked with ECO?
February 19th, 2007 at 3:02 pm
>When I started last May we had two database SQL connectivity technologies: dbExpress and BDP
Well, when you started last May, Delphi used to deliver the following database technologies:
BDE, ADO, dbExpress & BDP. Obviouly, ALL of them with pros and cons.
Beyond that, there were about over a hundred notable 3rd party technologies, based on:
1. specialized dataset descendents
2. multi-tier (midas) replacements
3. dbaware components, filling most of the gaps in db-vcl.
event today (.net 2.0/3.0), the dataset class is by far the best designed/most advanced database client side class/component on the planet. because of the so acclaimed also called "decoupled" model, .net lost deterministic design time state and mostly deals with a deeply crippled design time experience. microsoft tried to "patch" this deficiency (in vs 2005) by providing a rich set of class generators (obviously an inferior approach)
the last borcon, we were promissed by the ex-database team at borland that a fresh wave of innovation will bubble up, making sure that customers will:
1. have a db related reson to buy delphi 2007.
2. benefit from the extended design time experience, by being offered advanced / unique capabilities like "design time editing, design time transactions and design time master details"
3. extend the set of dbaware controls and provide dynamic wizards to make database designer’s daily life easier and more enjoyable, yet more productive
4. be able to provide dynamic properties support (talk to allen on this one) which is "a component should be able to create entire new properties at both design-time and run-time (mostly, while running).
5. be able to see/bridge collections as sets of records (that is, being able to load a tsortedcollection of "things", via rtti, into a dataset compatible manner)
*** we would like to know (as borland stack holders and customers) what happened with all these ideas and what are your concrete plans in reaching these goals.
thanks & best regards,
daniel
February 19th, 2007 at 4:09 pm
Daniel,
This list was passed on to me. Some of this I have heard informally from developers already. I started work in the Delphi team I was given the planned feature list created by our predecessors which was titled "Connectivity features". This list was primarily a BDP related collection of features. So most of what you describe above was not slated for this release by my predecessors.
Addressing connectivity was important for this release. We needed to provide features for native customers, we needed Unicode drivers, we needed to be able to keep up with ADO.NET 2.0. Consolidating the two existing architectures really helped to achieve these goals and gives us more bandwidth to address some of the non-connectivity features you have highlighted.
I am very interested in collecting more detail on your list above. It would be great if you could post this on our private newsgroup. This way we can have a threaded discussion and we at CodeGear can be more open in our replies.
-Steve
February 19th, 2007 at 4:34 pm
I do not have official access to any of your private newsgroups, but I would like to. However, my current Employer (US Gov) has a very strict confidentiality policy so, we may have to post pone some of these ideas for lighter times.
It is very unfortunate that none of your "predecessors" briefed you on these features… But we were clearly told about them at 2005′ BORCON (in San Francisco) and we (and other customers) expressed immediate traction to all of them! Ramesh mentioned some of them and there was another guy (Don? Dean? cannot remember his name) who kept asking us how about this, how about that… and he definitely made sense
I do believe that consolidating existing technologies and Unicode support are important goals. I do not see why you need to keep up with ADO.NET 2.0, since using base classes is an optional approach, implemented by Microsoft because of large customer demand to improve clarity in directions like 3rd party framework extensibility, by using true implementation inheritance, instead of simple contractual obligations (interface inheritance)… But that’s minor.
Regards & Good Luck,
Daniel
February 19th, 2007 at 5:13 pm
Ok. I’ll look into seeing if this was captured somewhere else.
February 19th, 2007 at 5:24 pm
Why would a team lead and senior architect say something like "So most of what you describe above was not slated for this release by my predecessors." Do you really have to depend on what your predecessors lated for your release? Just my 2c…
February 19th, 2007 at 5:41 pm
No, I don’t think I am capable of that.
What is most important to me is that we capture in detail what was discussed at Borcon 2005.
I will look into it.
-Steve
February 20th, 2007 at 12:22 am
Joe Hendricks,
Hi Joe,
We have been in contact the ECO team. They plan to support dbExpress 4 using the AdoDbx bridge. This will provide ECO access to dbExpress drivers.
-Steve
February 20th, 2007 at 3:24 am
"BDP is deprecated", imho this is a bad move.
BDP are quite easy to use, better than plain ADO.NET and can be a wonderful way to bridge old ASP.NET applications to brand new DBX drivers.
That’s what I’m trying to say. Don’t drop BDP please, because they’re a pleasure to use, much more so than plain ADO.NET .
Cheers,
Andrew
February 20th, 2007 at 3:25 am
"BDP is deprecated", imho this is a bad move.
BDP are quite easy to use, better than plain ADO.NET and can be a wonderful way to bridge old ASP.NET applications to brand new DBX drivers.
That’s what I’m trying to say. Don’t drop BDP please, because they’re a pleasure to use, much more so than plain ADO.NET .
Cheers,
Andrew
February 20th, 2007 at 6:23 am
I’ve checked with my team and other channels. The two Borland engineers we’ve talked with at Borcon are Ramesh Theivendran and Dan Marinescu. From our files, they do not work for you anymore (Ramesh is with a private entity in sillicon valley and Dan is at microsoft) so, good luck!
Regards,
Daniel
February 20th, 2007 at 8:03 pm
Steve,
What about the PostgreSQL dbexpress driver that shipped with Kylix, couldn’t that be leveraged somehow?
February 20th, 2007 at 9:22 pm
Tony,
I think I agree. The PostgreSQL driver that shipped with Kylix would help, but it does require resources to get into shape and to maintain it going forward. Its on the radar. Especially after the unexpected number of firebird/postgresSQL responses to this post. There are a lot of things we want to do and we can’t do them all at once. We are trying to make it as easy as possible to write dbExpress drivers. We provide source to the framework much like the vcl in the hopes that this will help driver writers.
-Steve
February 22nd, 2007 at 8:16 am
My vote for PostgreSQL support.
February 22nd, 2007 at 9:03 am
The power of persistence. In the mean time, I am willing to help provide direction to anyone that wants to write postgress/firebird drivers or adapt existing dbexpress 3 drivers to work with dbexpress 4.
February 22nd, 2007 at 12:12 pm
Yet another move..
We are using Delphi since its inception, Delphi 1. That was in 1995.
Before that, we had "Paradox". Still unparalleled.. Last month we had to exhume it for porting data from an Access application to an SQL server via Interbase and BDS2006. On this way, "Paradox 7.0 for Windows 95" turned out to be the best thing available on our way to correct data and alter structure easily…
But anyway..
We have thousands of lines of code with "TTable" all over the place. Why whould we change that ?
A table is a table.
What we just need, in the object inspector, under the "DatabaseName" heading is a list of databases.
The rest is up to you.
February 22nd, 2007 at 6:46 pm
Hi Michel,
DbExpress 4 should have minimal or no compatibility impact on existing dbExpress applications. There is more impact for ADO.NET applications because we are replacing BDP with an ADODbx bridge. However ADO.Net and BDP implement many of the same interfaces so there will still be significant compatibility there as well.
This change primarily impacts our existing connectivity offerings, not vcl components. Applications that use the existing DbExpress related TDataSet components should really not feel a negative impact. This includes the TClientDataSet and the SqlExpr TDataSets used for providing and resolving.
My sense is that you like working with the BDE based TDataSets more than the TClientDataSet and SqlExpr TDataSets.
Paradox provides a navigational access model where as the TClientDataSet uses a “set” oriented approach. A set oriented approach can be a little more work because you deal with smaller subsets of data, process resolution conflicts, and should/must perform your read and write data transactions as quickly as possible. This is what works best for transactional SQL servers. They scale better with short duration transactions.
We still have a lot of customers working with BDE. I’m interested in any more insight you can provide on why BDE is “Still unparalleled”. Is it that you don’t like the set oriented approach? You don’t like TClientDataSets? Something else?
Thanks,
-Steve
February 22nd, 2007 at 10:22 pm
Steve Shaughnessy,
I have not worked with ECO. I have heard of it and isn’t/wasn’t it a very expensive addon?
Isn’t this the Bold product that Borland bought?
February 23rd, 2007 at 5:53 am
Hello Steve,
When I said "Still unparalleled", I mentionned the Paradox product that was sold long ago by Borland to Corel. That was a real RAD product. Much more rapid than Delphi in fact but with less flexibility of course.
On the way, if I remember well, Borland kept the database system BDE and moved it to Delphi 1 and we followed. At that time we discovered the TDatabase, TTable and TDataSource components and started to use them, naturally. TDataModule came a bit later, Delphi 3 I think. That was also the time when Microsoft came with ODBC competing with the BDE "Idapi" idea.
Then came Windows NT and the jump from 16 to 32 bits and some problems started: Paradox tables were very reliable on Windows 16 bits but less on Windows NT. This was due to the fact that Windows NT retains the data into memory. Any time the computer had a power failure (in the industry it happens..) the paradox tables were corrupted. Then we moved everything to Interbase (still through BDE) and the problem was solved of course. That is still the situation today except that we also connect to Oracle and SQL Server on which most of the ERP solutions we connect to are running. Interbase is used on the client machines to store intermediate data before processing and storing into the central servers. It is also used for user inputs. Only because it is easier to use a DbGrid than a Grid!
Today on BDS 2006 what do we have ?
On one side, VCL and on the other Winforms, roughly speaking.
Putting us front of a very hard choice: Should we keep VCL or should we move to Winfoms ? Any time we create a projet, this question bubbles up. That is every day.
And behind this question the database connectivity issue. Please let me review this:
On the VCL side we have:
dbExpress: If we look at the TSQLConnection component, we see immediately that it can connect to ASA, Interbase and MySQL. What about SQL Server ? Oracle ? It is not a comprehensive solution, at least for the moment.
BDE: The old goodies with which.. let’s have a look : Access, DBase, Paradox, Excel, Informix, Interbase, Foxpro, Oracle, Text, SQL Server, Sybase.. far more comprehensive.
Interbase: yes Interbase has its own.. connectivity components: TIBTable, TIBQuery, etc. we never started in this direction. It would produce very specific code.
dbGO: We have seen this appearing on the pallet, don’t remember when and still trying to figure out what it is? Let’s have a look at this : In the provider list of the TADOConnection appears things like : ADsDSOOBJECT, DTSPackageDSO,..MDDataShape,.. etc. It looks strange and we are very cautious about it.
On the Winforms side we have:
"Data Components" with the SQLConnection component. We see the same list as in DBGo above, roughly.
"Borland Data Provider": There we have Interbase, MSAccess, MSSQL and MySQL.
What a mess !
Actually today, we are essentially waiting.
Last month however, we made a shy move toward BDP (which forces us apparently to move to Winforms which we do not want.. because another thing much more important is coming : Ajax). So this shy move we made it in an attempt to connect "in a modern way" to Oracle (with the Corelab BDP component) and to SQL Server. We made this move also because of the "disconnected architecture" brought to us by the .NET Dataset.
Why ?
Because today we reach in RAM capacities easily above 1GBytes.
Do we realize what it is ?
Let me take an example: We have some applications (data acquisition) that are running in the industry since now nearly ten years (the first one we delivered was with Delphi 3 – Delphi 1 was just for simulations and evaluations). The customers are rather large companies (not multinationals but not soho either) and their have stored over the years hundreds of thousands of records of data. First in Paradox tables and now in Interbase as I mentionned above. This database and its content, we do have a backup copy of it: On a USB sticker..
It weights 350 MBytes..
Beside this, now the hards disks are "3Gbits/s serial ATA" . Meaning that such a file (whatever its format) can be "persisted" on disk in less than 1 second !
What are we speaking about with this "SQL" business ?
Nothing anymore.
It has stopped to have a meaning.
The future is, for most applications, in data structures constructed in RAM. Flushed from time to time on disk, using some kind of Transactional File Systems, to ensure integrity.
That is why we consider the "Dataset as a set of tables" of .NET the centerpiece of all future developpements.
February 23rd, 2007 at 11:02 pm
Hi Michel Deby,
Thanks for your feedback. DbExpress supports more drivers than you may be aware of. This list includes Oracle, MSSQL, DB2, Interbase, Sybase ASA, Sybase ASE, Informix, and mysql. As you can tell from this blog we are getting significant number of votes for postgress and firebird as well. There are also more supplied by third party vendors. BDP supports a similar list. When we complete the ADODBX bridge later this year we will go from about 16 to 8 drivers. The bridge is a very thin delegation layer to the underlying dbx drivers.
You touched on all the Delphi data access options that have been provided over the years. This is something we must continue to improve on both from a runtime and tooling standpoint. And we will. We started off with connectivity because its important to a lot of customers, before we arrived most of the energy in the database group was being placed on .net, we needed a solution that would provide value for both native and .net customers, we didn’t want to unicode two sets of drivers, two sets of 16 drivers become 32 drivers when you go 64 bit, and so on. I still believe it was the right call to order this one first. At the same time we realize that things like data access components, multi-tier developemet, and tooling are also important to our customers. We actually have work in progress for all of these. We can’t do it all once, but we are moving pretty well so far.
Thanks again for taking the time to share your thoughts,
-Steve
February 25th, 2007 at 3:18 am
Hi Steve,
Thanks also to take the time to reply. There are of course issues we are not aware of, unicode, 64bits..
But the most important is done, through this post you gave details that help us to see the general direction we should go.
February 25th, 2007 at 7:45 am
My vote for PostgreSQL support too.
February 28th, 2007 at 8:58 pm
This Design makes me think…
Would it be possible to have a DBExpress Driver in the Chain acts a transport layer that communicates to a DBX Sever giving 3 tier support an existing DBExpress Application with no change in the client code other than which driver it was using?
March 5th, 2007 at 10:29 am
While I agree for the call for native Firebird support beyond depending on interbase compatability, making the system open source will DEFINITELY make it easier for us to address any CodeGear shortcomings in the area and I welcome it with open arms.
March 6th, 2007 at 2:04 am
Hopefully DBX4 will have a longer lifespan than BDP and older DBX. The rate at which borland/codegear has churned out "all-new" database access mechanisms numbs me. The demo code apps have stayed pretty much the same since Delphi 1.0 .. add/update/delete records using the data bound grid, master-detail view etc.
reminds me of the saying "old wine, new bottle". i hope you guys take a good look at any new features in .net 3.0 data access. Otherwise you’ll be setting yourself up to a deprecating BDX4 too on the next release of BDS.
March 13th, 2007 at 4:54 am
Steve,
We are now using InterBase with the InterBaseExpress (IBX) components in Delphi 2006. We want to support more databases in our applications and DBX4 seems like the perfect solution! Problem is… we can’t wait till we migrated to Delphi 2007.
The idea is to start with dbExpress 3 and later on move on to DBX4, will it then be easy to migrate to DBX4?
Also, FireBird support for DBX4 would be highly appreciated!
March 13th, 2007 at 12:12 pm
Oliver,
DbExpress makes it easier to switch between other database backends and will have some other features that IBX does not like delegate drivers and extensible commands. On the other hand, IBX has more Interbase specific capabilities.
At the VCL level there is very good compatibility between dbx3 and dbx4. So if you are working with VCL (i.e. the SQLExpr unit), migrating from dbx3 to dbx4 should be pretty smooth.
-Steve
March 13th, 2007 at 12:21 pm
Ray,
Yes.
-Steve
March 13th, 2007 at 5:48 pm
Are you going to support multiple indexes in DBX4, and will we be able to call Index.Locate directly?
In our company we’ve made a TDataSet-clone, to support for multiple Indexes (actually mirroring the way FieldDefs and Fields are designed: Next to IndexDefs we got actual Indexes we can call).
And what about thread-safety, will that become transparent? (Again, we’ve solved that issue by moving all dataset-state and related methods over to a handler instance we store in TLS; this way we don’t have to worry anymore about multiple threads using the same DataSet instance - obviously the MultipleRead-SingleWrite concept still applies)
March 16th, 2007 at 10:52 am
Please support Firebird.
I’m using Delphi 2006 with “driver” of interbase, I do not buy delphi 2007 because she does not have to driver dbexpress for firebird
March 30th, 2007 at 3:51 am
I Buy Delphi 2007 (not receive yet) and plan migrate our ERP Solution based on dbGO (ADO from Delphi 7) to DBX4. We use TADOConnection, TQuery, TProvider and TClientDataSet. What will be the impact in this our application in you opinion, and it´s a good idea?
Thank you.
May 3rd, 2007 at 1:09 pm
I vote for PostgreSQL support too.
June 11th, 2007 at 11:47 am
Another request for Firebord support
August 17th, 2007 at 12:50 am
I’m using Delphi.
Thanks for news info. Looks very useful.
August 24th, 2007 at 7:22 am
A vote for Firebird
August 30th, 2007 at 8:00 am
Once again a request for firebird!!!
September 2nd, 2007 at 2:05 pm
The demo code appz have stayed pretty much the same since Delphi 1.0.
add/update/delete records using the data bound grid, master-detail view etc.
September 23rd, 2007 at 2:46 am
Please support PostgreSQL.
October 1st, 2007 at 10:07 am
Please add support for PostgreSQL.
PostgreSQL support would make it easier for me to convince others to use Borland C++ 2007 and Turbo C++ 2006.
November 1st, 2007 at 1:10 pm
Good News
November 21st, 2007 at 1:08 pm
Really, please support PostgreSQL….
November 26th, 2007 at 6:10 am
Please support firebird….
December 2nd, 2007 at 5:03 am
thanks
December 7th, 2007 at 5:25 am
Firebird needs to be supported for us to continue to follow the Delphi upgrade path.
From reading previous posts it seems many of us still require connectivity to support our client’s legacy db systems. No one seems to want enhancements, just for it to still be included in future versions to avoid breaking existing code. Surely this cannot be too difficult?
December 15th, 2007 at 5:25 pm
thanks….
December 15th, 2007 at 5:26 pm
My vote for PostgreSQL support.
December 20th, 2007 at 1:33 am
sağolasınn
December 20th, 2007 at 1:33 am
süperrr
December 20th, 2007 at 3:08 am
thanks
December 27th, 2007 at 2:19 pm
Sevgi Ve Aşk Platformu SanaSevdam.Net
sevgi aşk gothic resimler
Sevgi Ve Aşk Platformu SanaSevdam.Net
December 27th, 2007 at 5:34 pm
Hello Steve,
thank you, the information about delphi was pretty helpful for us. We appreciate your effort.
Happy new year
Chiptuning Team
December 28th, 2007 at 10:38 am
thanksss
December 29th, 2007 at 6:47 am
Thanks
December 31st, 2007 at 10:28 am
thank you
January 4th, 2008 at 12:57 pm
bedava mp3 download sssssssss
January 6th, 2008 at 11:48 pm
Text is too wide for 1024×768. Even when scrolling as far left as the right margin allows.
January 7th, 2008 at 6:59 am
I agree this article is very helpful.
I have been reading about how to improve mt article writing,
but it would be nice if I actually had some visitors which left some input.
I think that could help me to improve my blog..
January 7th, 2008 at 11:24 am
thank you.
January 8th, 2008 at 6:10 am
It’s really good written and I fully agree with You on main issue, btw. I must say that I really enjoyed reading all of Your posts. It’s interesting to read ideas, and observations from someone else’s point of view…
January 12th, 2008 at 5:42 am
Thanks
January 16th, 2008 at 8:13 am
thanks a lot
January 18th, 2008 at 2:00 am
Great article. Thanks and greetings!
January 23rd, 2008 at 2:03 pm
It’s very good article. Great site with very good look and perfect information.
February 11th, 2008 at 9:41 pm
thanksss
February 12th, 2008 at 9:48 am
Please support Firebird.
I’m using Delphi 2006 with “driver” of interbase, I do not buy delphi 2007 because she does not have to driver dbexpress for firebird
February 15th, 2008 at 1:00 pm
Really, please support PostgreSQL….
February 21st, 2008 at 10:10 am
Thanks for this really useful article.Great cheat sheet, I appreciate it very much.
February 26th, 2008 at 12:02 am
I agree with all your suggestions
March 1st, 2008 at 2:16 am
thankssssssssssssss
March 1st, 2008 at 10:35 am
I agree with all your suggestions
March 1st, 2008 at 10:36 am
thanks…
March 3rd, 2008 at 4:57 am
thanx for artichle
March 4th, 2008 at 5:01 am
thanks soo much
March 4th, 2008 at 5:47 pm
It’s great to see some good decisions being made at CodeGear. I was hoping for some more innovative technology, perhaps object-to-relational mapping, etc. Delphi has always made the simple database app very easy, but when trying to put your business logic in a middle tier, the programming can get tedious.
March 7th, 2008 at 12:33 am
Thanks very much
March 7th, 2008 at 4:06 am
thanks……
March 7th, 2008 at 2:27 pm
dank u
March 7th, 2008 at 2:28 pm
dank u
March 12th, 2008 at 6:28 am
It’s great to see some good decisions being made at CodeGear. I was hoping for some more innovative technology, perhaps object-to-relational mapping, etc. Delphi has always made the simple database app very easy, but when trying to put your business logic in a middle tier, the programming can get tedious.
oyun
March 12th, 2008 at 6:29 am
but when trying to put your business logic in a middle oyuntier, the programming can get tedious.
March 14th, 2008 at 12:15 pm
Successful website
March 16th, 2008 at 6:36 pm
Thank you..
March 18th, 2008 at 7:42 am
thanks.
March 20th, 2008 at 8:43 am
Great work, though.. Thanks much!
March 20th, 2008 at 9:07 am
thanks canlı tv
March 21st, 2008 at 1:23 pm
thanksssssss admin
March 21st, 2008 at 1:35 pm
thanksssss
March 23rd, 2008 at 2:12 am
Very useful, thanks…
March 23rd, 2008 at 2:13 am
Thanks, great.
March 25th, 2008 at 8:31 am
thanks
March 25th, 2008 at 8:32 am
very good
March 30th, 2008 at 4:03 am
Thanks a lot.
April 2nd, 2008 at 10:03 am
great article
April 3rd, 2008 at 2:14 am
good article good information
April 5th, 2008 at 2:41 am
very beatiful
thanks man
April 6th, 2008 at 9:57 am
very beatiful
thanks man
April 9th, 2008 at 3:50 pm
Thanks a lot….
April 13th, 2008 at 7:50 am
Thank you very much. Regards.
April 14th, 2008 at 6:54 pm
thanks a lot..
April 19th, 2008 at 5:31 pm
harika bir site sagolun
April 19th, 2008 at 6:24 pm
Teşekkürler bro.
April 23rd, 2008 at 10:33 pm
Thanks
April 24th, 2008 at 6:29 am
Nice post. Well done. Thanks.
April 24th, 2008 at 6:30 am
Really impressive. Thanks.
June 2nd, 2008 at 1:04 am
thanks a lot..
June 2nd, 2008 at 1:05 am
very beatiful!!thanks!
June 14th, 2008 at 7:12 am
thanks
July 9th, 2008 at 10:30 am
here is my first release of DBX4 driver for PostgreSQL.
http://whitekid.tistory.com/108
July 10th, 2008 at 7:56 am
thank you so much
http://www.bayrakline.com
July 14th, 2008 at 7:22 am
thank you..
hekimboard
July 20th, 2008 at 3:02 pm
Thank You
August 4th, 2008 at 3:05 pm
Thanks very nice.
August 4th, 2008 at 3:10 pm
Oh nice.
August 4th, 2008 at 3:11 pm
Thanks you.
August 15th, 2008 at 4:21 pm
whitekid, great work.
But I have a error while trying to connect to my postgreSQL DB using your demo program. I’m getting the error:
Syntax error near "."
LINE 1: SET TIME ZONE 1.0
(d:\My Document\workspace\dbxpg4\src\libpq\Wrapper.pas line 128)
The path must be from your machine as I do not have such a path
I’m suing the version 0.2.0 of your drivers.
Can you please help?
August 16th, 2008 at 11:30 am
Congrulations for this nice web design..Usefull..
August 16th, 2008 at 11:31 am
Thanks, for this information and news it was very useful to me
August 16th, 2008 at 11:37 am
Wow…This is what i need..thanks…
September 27th, 2008 at 9:04 am
Thanks for info
October 12th, 2008 at 6:35 am
very thanks for you!!! Oyunlar
October 21st, 2008 at 12:50 pm
Thanks very good
November 22nd, 2008 at 8:11 am
madalya imalatı ve satisi http://www.fulminaksesuar.com thanks
December 8th, 2008 at 4:07 am
[...] DataSnap architecture, based on DBX, for lightweight, client/server [...]
January 3rd, 2009 at 6:33 am
Thanks, for this information and news it was very useful to me
http://www.cokmuhabbet.com
January 3rd, 2009 at 6:36 am
thanks
January 12th, 2009 at 5:32 am
whitekid, great work.
But I have a error while trying to connect to my postgreSQL DB using your demo program. I’m getting the error:
Syntax error near "."
January 13th, 2009 at 5:05 pm
thanks for this post
January 18th, 2009 at 7:19 pm
Thanks very good
February 13th, 2009 at 5:32 am
oyunim