Delphi 2007 Handbook








January 19, 2007

From BDE to dbExpress (by Ethea)

Some friends of mine have released an interesting set of components and some guidelines for moving very old projects to a newer architecture.

My friends at Ethea, who are also actively working on InstantObjects, have released InstantBDExpress. It is a set of components and guidelines for moving BDE applications to dbExpress. Components provide compatible properties remapped to a client/server architecture. Guildelines provide help and suggestions for migrating the code. This is based on their real-world experience in helping customers migrate some large projects over the years. Of course, beside the tools they also offer consulting.

I know Nando and Carlo quite well, as they've worked for my training company many times. I'm probably too biased to recommend their work, but I trust their expertise and have relied on it, so I think you won't be disappointed...

posted by marcocantu @ 10:34AM | 3 Comments [0 Pending]




 

3 Comments

From BDE to dbExpress (by Ethea)  

 speaking from experience, in moving from BDE to 
DBExpress, a few property names are the least of the 
problems.

Behavioural changes are the big issue.  Transaction 
handling is totally different as is locking, and 
locking is a HUGE issue when moving from BDE which 
does agressive locking as you edit a record, whereas 
c/s databases only lock a record as you update it 
inside a short lived transaction.

Even if you manage to use the same components, the 
end user experience is VERY different.  Grid editing 
is practically useless away from the BDE as a result.
Comment by Xepol on January 21, 05:18

From BDE to dbExpress (by Ethea)  

I agree that a few property names are the least of the
problems when moving from the BDE to dbX, and that the
main differences are behavioural. That's why IBDX
emulates both interface *and* behaviour of the BDE, as
long as practical.

The BDE works differently with local files and SQL
databases. The locking behaviour described by Xepol
(pessimistic locking) is done on local files, not SQL
databases (where it uses optimistic locking instead).
What IBDX emulates is the BDE's behaviour with SQL
databases, although we were able to convert projects
that used pessimistic locking as well.

I disagree about grid editing being useless without
the BDE. Grid editing is as useful as with the BDE if
you use IBDX. Not so if you use plain dbX, but that's
why IBDX exists in the first place. :-)
Comment by Nando Dessena [http://www.ethea.it] on January 23, 12:57

From BDE to dbExpress (by Ethea)  

Grid editing is OK with any database as long as it 
is the proper interface in a given situation. If one 
plans to fetch half a database into a grid, search 
for a record within the grid and edit it, well, no, 
it's the wrong way.
If one uses a grid to edit a small, focused subset 
of records with little conflict probability on 
insert/update, and is prepared to handle conflicts, 
well, grids are useful as ever. I guess the 
QuantumGrid is not sold to BDE users only... :)
Comment by Luigi D. Sandon on January 23, 16:04


Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.