Re: Evaluating D2005, help needed.

"Richard Grossman" wrote
> Angra Mainyu wrote:
<snip>
> Unfortunately, I can't drag any of the tables onto the form.
<snip>
> Sadly, you have somehow suckered me into a timehole because I hate to
> give up.
<snip>
> Anyway, I've killed 30 minutes and gotten even more confused. There's
> no visual component on the form although there is an element in the
> project for the datasource, but I don't see where I would do something
> like enter actual SQL etc.
<snip>
> PS: Your step7 has a line of code, thus negating your side of the
> argument, and eliminating the point of this futile exercise.

At this point I'm responding to two claims you made in two different threads
both of which I've questioned. These quotes contain the essence of the claims.

Your claim #1
> The pure thoughtless and blind uselessnes of VS 2003 having visual
> components that require code to link them together is astounding, and
> caused me to immediately and totally discredit all of the pro-VS
> commentary in this newsgroup.

Your claim #2
> I'm finding completely useless all the hypothetical posts about VS2005
> being a solution to the problems in D2005.
>
> Let's face it, the real problem is that at this point, the decline in
> quality of Delphi still hasn't crossed below the productivity of Visual
> Studio. So many who bemoan their fate still can't get a payoff from
> switching.

Your claim #1 was specific to VS.NET 2003 and to refute that claim I presented a
detailed 8 step procedure to create an actual running database application that
proves that your claim is false. It was meant for VS.NET 2003 since that is the
version you were totally discrediting. Your claim #2 concerns the productivity
of VS.NET 2005 and I have asked for some confirming data which you haven't yet
supplied.

Because of the broad and sweeping nature of both of your claims, I naturally
assumed you had aquired more than just a passing look-see experience with VS.NET
and had built several database test cases to backup your claims but now it seems
to me that my assumption is woefully incorrect.

My guess based on your attempt to carry out the 8 step procedure leads me to
think this could well be your first attempt to build a test database application
using VS.NET. It also appears that you were using the beta of VS.NET 2005 and
there are subtle differences between the two versions that could make the
write-up slightly confusing. Over the past couple of years I have used that same
8 step procedure several times to show people how to quickly build a test
database app in VS.NET 2003 by hooking-up components is a RAD manner. It *does*
work - why I've even seen whiney tiny-tots use it with great success. ;-)

Now about your comment "PS: Your step7 has a line of code, thus negating...".
That one line of code has nothing at all to do with hooking-up components, what
it actually does is Open a Connection to the database, execute the SQL statement
embeded in the DataAdaptor's Select Command, Fill the DataSet with the resultant
data coming from the Customers table of the database, Close the Connection, and
finally cause the data to be displayed in the DataGrid component.

IMO your claims lack the creditability of the knowledge and proficiency gained
through a considerable amount of hands-on experience with VS.NET. And, in the
case of Claim #1, is demonstrability false as I have shown.

Your Claim #2 is not one I would have made, either for or against. I have 10
years experience with Delphi 1-7 and almost 5 years with VS.NET - I started back
when the first public beta of VS 7 was released. At this point in time I use
Delphi for Win32 and VS.NET for .NET and while I'm quite confident that my
productivity is higher in VS.NET than Delphi, I certainly wouldn't automatically
assume that others would reach the same conclusion, especially those who have
only limited VS.NET experience. As they say YMMV.

I have been thinking about how one might design an experiment to gather evidence
that would allow one to draw inferences about the relative usability and
productivity of Delphi and VS.NET and if anyone is interested I could share my
thoughts. It could be interesting...




.

Relevant Pages

  • Re: ODB (Cache?) vs ORM
    ... This is common and accepted database knowledge. ... > other way is error-prone, thus virtually guaranteed to break integrity, producing ... > is multiple orders of magnitude more powerful than procedural optimization. ...
    (comp.lang.java.databases)
  • Re: OOP database tables <-> php interface (semi LONG)
    ... The Access database has over 30 ... database and business object layers. ... Good point about the flexibility too! ...
    (comp.lang.php)
  • Re: Transforming ascii file (pseduo database) into proper database
    ... contained therein so that it can be inserted into an existing database. ... So I iterate over the file maintaining a list of calls for the given phonenumber, and when the phonenumber changes, I deal with the previous cache of data, then re-initialize with the new phone's data. ... create a temp DB, skim through the file inserting all your data into a table in this DB, then use DB functionality on it ...
    (comp.lang.python)
  • Re: After some advice for improving coding skills
    ... >procedure names should be verbs and function names should be nouns or verbs. ... any idiosyncratic layout of your code. ... Write Delphi as Delphi is meant to be written ...
    (comp.lang.pascal.delphi.misc)
  • Re: Delphi 6 has become flaky and unusable - AV in module coreide60.bpl
    ... >Delphi 6 has been working fine for a number of years. ... Does it load a project on startup? ... Since it is the IDE that is blowing itself into tiny pieces, ...
    (borland.public.delphi.non-technical)