January 19, 2007
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]
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
There are currently 0 pending (unapproved) messages.
