Delphi 2006 and SQL Server

Congratulations to all the guys at Borland. Delphi 2006 is a great
product and will hopefully be every bit as successful as it deserves to
be. I do have some concerns though about certain aspects of the product
which I wish to express here. BDS is still a relatively new product and
it appeals to such a vast array of developers that it could never be
perfect for everyone from day 1. I hope that Borland continues to take
the views and opinions from us in the Delphi community to heart to make
Delphi even better than it is today.

The application that I have developed is a Delphi VCL Win32
client/server application that accesses a SQL Server database. Up until
now I have done all my coding in Delphi 7 and I feel I am ready to port
my application to Delphi 2006. There are serious decisions I have to
make regarding the future architecture of the application. I basically
have to choose one of the following:
* Stick with VCL for Win32 + dbGo
* Port the application to VCL for .NET
* Rewrite the entire application in Windows Forms in Delphi/C#

At this stage, the best idea seems to be to port the application to VCL
for .NET. The main reasons for this decision is to open up my
application to the .NET world while not having to rewrite everything.
>>From what I've read, the VCL is richer than Windows Forms, which may
disappear when Avalon arrives anyway. What I would like to do is port
my data access to ADO.NET and use the VCL ADO.NET connector to
communicate with my VCL controls. This is where Delphi 2006 is a bit of
a let-down. While I welcome the conversion of dbGo to .NET, I feel that
there has not been enough emphasis at Borland to support SQL Server.
SQL Server is the one of the most widely used enterprise database out
there (at the lanuch of SQL 2005, microsoft said that last year they
sold more SQL Server licenses than Oracle and IBM combined).

After experimenting with SQL Server connectivity in Delphi 2006, I have
the following concerns:
* There is no way to drag/drop ADO.NET SQL objects (e.g. stored
procedures) onto a form. The Borland IDE only supports dragging and
dropping of BDP.NET objects
* This means that if I do not wish to use BDP.NET I have to manually
set up SQL Server objects. E.g. I would have to manually define the
parameters of every Stored Procedure I link to a SQLCommand - This
would take a ridiculously long time compared to what I'm used to with
dbGo, where a click of a button does this for me.
* The performance of dbGo.NET seems to be quite slow. Maybe I haven't
had enough experience with this, but running a simple dbGo benchmark
under Win32 is alot faster than under .NET
* When discovering the SQL Server Reporting Services web services, the
Delphi unit that the IDE generates does not compile because of errors.

My main concern is the fact that Delphi 2006 forces me to use BDP.NET.
I work in a mixed environment where some programmers work on projects
written in Visual Studio.NET. Our aim as a development house is to
share source code as much as possible accross the different programming
environments - this is what .NET is supposed to be all about. Being
forced to use a vendor-specific technology such as BDP.NET just isn't
suitable in our envornment.

I strongly believe that the best way to lure Visual Studio developers
is better support for SQL Server. After all, SQL Server is a large
piece of Microsoft's .NET puzzle.

My wishlist for the next version of Delphi would be to do the
following:
* Support ADO.NET in the Database Explorer
* Allow for automatic populating of stored procedure parameters in
SQLCommand objects
* Wrap the SQL ADO.NET objects inside VCL controls like dbGo is a
wrapper for ADO
* Support all the new features of ADO.NET V2 including being able to
write Delphi DLLs that run inside SQL Server 2005
* Include built-in support for new SQL Server components, such as
Reporting Services and SSIS

I'm the first to admit that there's more to life than just SQL Server,
but this is a major part of my job and I'm keen to enter the .NET world
with Delphi as my tool of choice.

Regards,

Larry Roth
Cape Town
South Africa

.