Database Landscape for future Delphi work.

I'm a died-in-the-wool Delphi fan, and have been programming in Delphi since
Delphi 2. The main application I produce is a personal contact manager for
missionaries around the world. The "around the world" part of this is what
drove me to embrace Unicode early on and to work on making it possible to
produce a fully Unicode-enabled application in Delphi since Delphi 5 (before
Delphi.NET). This last year I've been working on some ASP.NET projects in
Delphi, and with this experience in .NET I'm more than ready to make the
jump to .NET and port my main application to .NET.

This personal contact manager that I'm going to port started off a long time
ago based on Paradox/BDE. As I got closer to releasing it publicly I felt
uneasy about the deployment aspect of the BDE. Also I didn't like the fact
that the database was not a single file, but rather a collection of files
within a folder. I felt this would be too error prone for users to manage.
So I switched my database to Jet 4.0 (MS Access) and to using ADO via Delphi's
new TADODataSet (Ado Express / dbGo for ADO). I believe I made the right
decision, particularly w/ Jet 4.0 for a local in-process single-file
database. Thankfully the VCL.NET includes TADODataSet, so I should be able
to port my application to VCL.NET without much difficulty (that's the idea
at least!).

After I port my application to Delphi.NET (using ADO to talk to Jet), I want
to stop and evaluate the database landscape. I've used ADO.NET, and it has
some nice features, but I really like the live-cursor aspect of using ADO
against Jet (in-process). IMO: ADO.NET has too many moving parts and
multiple-steps for a single-user file-based database application. When I
call DataSet.Post, I want the record to be saved to the database
immediately!

So I'm trying to think through some different scenarios for
embedded/in-process databases:

Stick with JET backend, using ADO or ADO.NET as necessary:
PRO: No code has to be rewritten. I have experience w/ JET. My users
can open my database back-end w/ Access when they need to do something my
app can't.
CON: JET seems to be a dead technology w/ no further support from
Microsoft. Am I wrong? JET is tied to Windows.

SQL Server Compact Edition:
PRO: Good support for syncing w/ SQL Server.
CON: The database is tied to Windows (not cross-platform). I'd have to
switch to ADO.NET. Although SqlCeResultSet looks a lot like ADO w/ live
cursors.

VistaDB:
PRO: Fully written in .NET, works on Mono and Compact Framework. Very
T-SQL like syntax. Future support for MS Sync Services.
CON: I'd have to switch to ADO.NET. Although their DDA classes have
live-cursors.

BlackFishSQL/DbExpress:
PRO: Fully written in .NET. Future support for CF planned. (Mono
support?) The Delphi IDE will have good support for this particular path (I
assume) so I wouldn't be fighting the tool to get my work done.
CON: I don't have a clue about DbExpress. Does it require a
TClientDataSet for TDataSet support? Does it provide live-cursor support in
a TDataSet? Can DbExpress talk to MS Access or VistaDB? Is DbExpress much
like ADO.NET w/ all the same "moving parts"?

Another radical leap for me to think about is some type of O/R mapping
layer. The .NET ecosystem seems to be full of them, and w/ Linq coming,
perhaps this is the future? DevExpress XPO seems pretty good for what I'm
looking for. But there's probably a zillion others!

Any constructive feedback on this would be much appreciated!

--Troy



.

Relevant Pages

  • Re: If you want to talk to [the] Oracle, go to Delphi.
    ... PowerBuilder was often touted as having much better database ... > support than Delphi. ... > the network traffic talking to Oracle than Delphi did. ... good support for various database vendors and it worked as expected ...
    (borland.public.delphi.non-technical)
  • ANN: NexusDB 1.01 - New Features
    ... Nexus Database Systems is pleased to announce NexusDB 1.01 for Delphi 5,6,7 ... Rivals pure memory-based database engines on speed on smaller datasets, ... Support for the IProvider interface is included. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Delphi 2005 Personal edition
    ... > Does anyone know if the Personal Edition has any ... > personal editions, without any database features. ... Database support is the only thing in Delphi ...
    (borland.public.delphi.non-technical)
  • Re: Replacement for delphi
    ... The database is freely available though. ... If they did support it, Delphi might get some new customers. ...
    (borland.public.delphi.non-technical)
  • Re: Programmatically creating an Access/Jet database
    ... Thanks for the info Michael. ... Actually i'm just using MS Jet. ... I wonder what database DOES support ...
    (microsoft.public.dotnet.languages.vb)