This is kind of a tough topic to categorize because it involves so
many different things, so I thought this would be the best place to post it.
As many of you know I've been doing quite a bit of experimentation
with NET, but what you MAY not know is that these test projects I've been
working on have been completed concurrently in Delphi Win32, Delphi NET, and
VS2003 w/Chrome! The reason for this should be obvious to most...I wanted
to see just what the real-world differences would be in design, coding, and
running these applications so that making choices, of which there are so
many today would NOT be dependent purely on my likes or dislikes for any
particular IDE or method. Also, as performance has been a big subject since
NET arrived, and so many have said they feel NET apps run slowly compared to
Win32 I thought this would be the best way to find out. It is important to
note however that in no way should my results be taken as scientifically
accurate because I used no testing code or timing utilities in these tests.
All results are purely subjective!
First, let me outline the application. A simple desktop app which
will upon starting open and display the 'Products" table information stored
in the commonly used Northwind dB demo. This table comes with many
different dB engines and can be found all over the net in many formats, and
for this purpose I used it in two formats only. One in the format used by
Nexus Version 2.02 and the other as used by VistaDB 2.1.
I used only basic forms and components provided by each IDE. Each
one consisted of a main form or in the case of NET a main Winform, buttons,
and a DataGrid and DataSet component. Beyond these only those particular
components as required by the needs of the particular application and it's
dB system. I won't go into the details or specifics of each application as
they are all very basic, besides it's the results that are of interest.
Win32
This app took about 15 minutes to put together in Delphi, and to be
fair I used ONLY the mainform...no DataModule as I normally would. The
Nexus DataBase required an embedded server component, a database component,
a DataSource component, a Navigator, a AllEngines component, a Session
compoenent and a Table component, AND the addition of their memory manager
to the project files, (dpr), uses clause, and quite a few to that of the
MainForm as well. Normal Delphi database methods were used so as to have
direct access to the table. In this app however I coded no access at all,
merely pointed the database component at the proper file and hooked up the
DataSource, Navigator, and Grid. The only code that had to be written was
that as required to open the database up and to close it when finished.
DelphiNET
In this version the big problem was that the Nexus ADO provider is
still not working properly and so I was unable to test against the same
engine. So here I used the VistaDB and TRIED to use it's DDA, ( Direct Data
Access ), methods as I did later in the VS app but was unable to. It
appears that it would require a special driver made for Delphi. And though
VistaDB is made to work with Delphi win32 as well as all common NET
languages, I was unable to find a substitute that worked. It may have more
to do with the way Delphi NET works as well...I really can't say but I was
hoping perhaps Bob Swart or someone else might be able to comment on this as
I'd really like to know myself!
In any case I found the ADO methodology very difficult to work with
and even a bit more difficult to understand. The way DataSets are used and
the TableMapping methods are quite different than one might be used to if
they built dB's the "Delphi way", so it took me well over an hour to get
this one working correctly. To be fair however, now that I know what I'm
doing with it I couldn't imagine it taking more than 15 or 20 minutes top.
The hardest part, beyond the differences in data access were in how
namespaces are qualified in Delphi NET. This can be rather confusing as
well, and I hope for Borland's sake that they find a way to incorporate a
VCL in NET without having to change things around as they have in D2005!
In this application I didn't even need to open or close the
database! After adding my types I merely had to write one line of code
calling the DataGrid's fill method at startup, but then because no direct
access could be used, I also had to code each of the basic commands needed,
such as Insert, Delete, etc. Most of the time involved was due to how
strange it is to set up the mappings the first time.
VS 2003 w/Chrome Pascal
This was believe it or not the easiest by far to set up, understand,
and get working! All that was necessary for this version was to add the
VistaDB namespace to my mainform uses clause AFTER adding it to the
references section of my Solution, ( project ), and then three lines of code
in my MainForm's public constructor...one each for a DataBase, a Table, and
a DataSet, to set their names and types just as in DelphiWin32 or Delphi NET
above, except here I did not use the components, instead I wanted to try
creating them manually in code just to see how different it was from doing
the same thing in Delphi. As an example, to create an instance of a
DataSet named 'vDataSet' the following is the code needed:
vDataSet := new VistaDBDataSet;
but Chrome also provides a compiler setting allowing you to use the standard
Create calls we're all used to in addition to using the 'new' keyword. This
really helps lower the confusion!
Here's the full code from my mainform's Load method. As you'll note
all of this can be deleted by simply dropping the components onto the
designer and setting a few properties, but I find it easier to learn and
retain new things like this when I force myself to do so manually!
vdb := new vistadbdatabase('C:\Program Files\VistaDB
2.1\Data\NorthWind.vdb');
vDataSet := new VistaDBDataSet;
vTable := new VistaDBTable(vdb);
vTable.TableName := 'Products';
vDataSet.DataBase := vdb;
vDataSet.TableName := 'Products';
vDataSet.IsOpened := True;
dataGrid1.DataSource := vDataSet;
As I was able to use the direct access methods in this version I did
NOT need an ADO .NETAdapter, and was able to code all the necessary events
to work with the database the "Delphi way", but here in place of using a
Navigator or a bunch of buttons each connected to one of these methods, I
used only three. One for Prior, one for Next, and one for Update. No
loading, opening or closing was necessary, and if I wanted to I could 'lift'
from previous Delphi Win32 applications I've written much of the code I use
for security and user validation, even that which allows me to set the
database to a different directory at runtime based upon the currently logged
on username! The same could also be done in the DelphiNET app above!
Writing this version was very intuitive and fast. Because I didn't
have to worry about changes in the way namespaces are used and qualified,
and because using DDA allows one to use Delphi-like methods and all the
extra components required by Nexus weren't needed here, it took me less than
10 minutes to have it up and running.
Results:
As I said, without any special timing utilities it's impossible to
compare performance and get exact figures, but this much I can say. I
noticed no differences at runtime between the Win32 version and the VistaDB
DDA version. In both the Northwind database table was loaded as the
mainform appeared on screen, and both of these ran immediately if not sooner
when I clicked a shortcut to their respective exe's. The same was true of
all other commands such as appending or deleting, but not so surprisingly,
the Delphi Win32 version was slightly larger and used more memory, but not
enough to worry over in any case!
Comparing either of these two versions to the Delphi NET using ADO
version however WAS very easy because the difference in load and access time
could be seen with the naked eye! I could easily count off nearly two
seconds before the mainform appeared with it's Grid loaded. Once loaded
however things seemed just as fast as with the others with a performance
difference you really have to look for to notice at all. This is due I'm
told because ADO of the fact that it is just another layer on top of
everything else.
Needless to say, I've been getting more and more impressed with NET
every day I've used it! In so many ways it's easier to understand and work
with than Win32 is, and the clr includes a lot of what many of us have
formerly needed 3rd-party libraries for. The current version of Delphi for
NET is most certainly better than that which was provided by D8, but it
still has a way to go before it's as easy to work with and understand as in
VS w/Chrome! It DOES appear though that Borland may be making an effort to
make their Delphi NET !100% compliant, and IF they can succeed in that AND
still provide an excellent VCL for NET at the same time, look out! That
will be a tough combination to beat! So although I can't see myself
upgrading this time around as I said before, I WILL be watching carefully.
In the meantime VS and Chrome make a pretty unbeatable combination
themselves, offering not only new and improved syntaxical changes to the
basic Pascal language, but also things like included compact net
capabilities, the ability to use NET 2 in VS 2003 if you want, saving you
from having to upgrade to the new VS 2005 if you'd rather not...in fact you
can easily with Chrome target both at the same time! I also have to admit
that the VS2003 IDE is pretty dam good all by itself, and when the free
DPack is added and/or Coderush it's even better! It's debugging abilities
are absolutely fantastic and can be used equally from within the graphical
IDE or by a command-line method. And if you like Codesite as I do you can
hook that right in as well and with Vs's own libraries get full error
information including stack tracing and line numbers, sending the info
directly to the Codesite viewer without having to use any 3rd-party
libraries or components!
As for databases in either case, it's a bit difficult to say at this
time if anyone if better than another for a lot of reasons, including the
fact that everybody has their own favorite ways of working with them and
their own class of application type that they do more often than any other.
You've heard me talk about Nexus a few times, and how much I liked
working with that particular product. And also I was impressed by the
people behind the product and how they were bucking the system in coming out
with their engine at such a price and with such capabilities at this time.
Unfortunately I can no longer recommend them, and for a number of good
reasons, none of which have anything to do with performance factors.
I had only used basic table methods....again in the "Delphi
way"...to create mostly embedded Win32 applications used for small
businesses. In that, Nexus is very good. Stable, easy to work with, and
fully embedded. But a lot of what I also liked about Nexus was in the
promise it held for the future! For example, the promise of a good ADO net
provider. And even more was supposed to be found within features I had not
used yet but planned on using as soon as I moved closer to NET myself!
Unfortunately for me and many other Nexus users, this promise has
not come true. Here in the States we have "Truth in Advertising" laws but
elsewhere it's not quite the same, and almost ANY excuse can be used for a
product NOT holding up to it's own specifications and hype! Version 1
released two years ago at a cost just under $400 was supposed to include a
full and better than standard SQL implementation. And things like
Referential integrity, full text search, and more had been promised to us as
well. The ADO provider was also promised to be available soon, and in
particular I really needed that!
We're already nearly six months into version 2's release with a
number of point releases already having been made, and still the SQL cannot
be depended on, with even common commands like JOIN causing problems. Full
text Search is now being touted as an extra to be developed in the future,
and the ADO Provider in it's 12th beta release still cannot be used! In
addition, IF and WHEN the ADO provider is released it will be as a separate
product at a hefty price by itself just as their OBDC driver now is! What
was originally advertised as Royalty free is now being changed too, and in
the last two weeks literally hundreds of messages fill the thread they
themselves started on debating new pricing methods and paid support fees to
be instituted when Version 3 comes out!
There's a lot more to the Nexus story but suffice it to say they
have succumbed to the same kind of thinking as Borland, which is to announce
and sell a product that doesn't live up to it's claims and then put their
customers thru endless rounds of trial and fix., instead of running beta
trials long enough to guarantee their products are worthy. Personally
speaking I'm done with being used by them or anyone else who wants to play
that game, and from now on unless a product's seller/author can provide me
with a good enough reason to wait for a fix, and then only in the case of
minor bugs, I will not accept ANY excuse and will demand my money back when
it doesn't work as advertised.
Now as for the vistaDB suite, I have to say in order to be fair that
I have not yet tried it out on a Win32 Delphi application. But when used in
a NET environment like VS and Chrome it seems superb so far. I won't list
all that it can do as you can easily find that information on it's fact
sheet at their Web Site, but this much I will say. As it stands right now
it is everything Nexus had promised to be AND a lot more! Until Nov 15th it
can be bought at a special price $100 less than usual, making it under$300
and one of the cheapest alternatives around! It allows fully embedded NET
and Win32 Delphi apps and/or full S/S types, and has a very low cost when
you get into big multi-user situations. In NET, unlike most other products,
It allows one to use SQL or DDA depending upon your needs, and as I found
out while working on the above examples, it is extremely easy to use!
Unlike I used to do, I won't recommend it, but I am buying a copy for myself
if that means anything at all. For that price even I can afford to be
wrong, but I don't think I am!
Here's hoping this long post is of some help and/or inspiration to
others!
from: Robert Meek at: [EMAIL PROTECTED]
dba "Tangentals Design" home of "PoBoy"
freeware Windows apps and utilities
located at: www.TangentalsDesign.com
Proud to be a moderator for the
"Delphi Programming Lists" at: elists.org
__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi-talk
