Dear Ajit,

I find myself in the reverse situation as you, but I somewhat empathize
with you.

(By reverse, I mean, I started with Delphi before going into Visual
Basic. In Delphi, things are much easier but the learning curve is steep
because of the lack in books - especially back in 1996.

On the other hand, Visual Studio is a lot messier compared to Delphi -
that's probably why you are looking for so many other things - but the
learning curve is a lot flatter because there are so many books that can
explain to you the 100 'simple' steps to do to display a message on
screen - exaggerated to emphasize a point.)

First, let me welcome you to a community of pioneers. I say this because
every newbie will find himself in unchartered waters. (Unchartered
intended and not a misspelling of uncharted).

IBO as well as Interbase is not uncharted because once you get over the
initial learning curve, you will find that these bare bones examples are
all the techniques you need to build rapidly a client/server
application.

IBO may look light on the outside but that's because Jason has done the
heavy duty work inside.

But you are in unchartered territory because unlike Visual Basic and
Visual C++ or even Oracle, you will not find a single published book in
English about Interbase (other than the manual), and the IBO handbook
and IBO files are about all the learning tools you have to get you
started.

It is unchartered because unlike the market-oriented MS products, no
publisher has 'CHARTERED' the Interbase experts to write books on IBO
and Interbase.

Some years back, I hitched into the Visual Studio world and Oracle also,
and the learning curve is a lot flatter because there are lots and lots
of books on the subject. But I found that while, these books explain in
clear and concise way the 50 simple steps on how to do something in MFC.
(But the parallel can be done in Delphi using 4 steps. But these four
steps, I had to discover for months and months because finding a way to
do simple things like this is like finding a needle in a haystack.)

These MS books explain so many concepts and take so many chapters and
look complicated. And these are all unnecessary in the Delphi /
Interbase / IBO world. I remember while going over the MFC, after going
over several books on the topic, I somewhat concluded that on the
average, 7 chapters of MFC is equivalent to one chapter in Delphi. (But
the irony is, it is just so hard to discover where that single chapter
is - back then... But you're lucky, things seem to be a lot easier these
days, especially if you subscribe to the community website of Borland).

The irony is, I began to appreciate Delphi more, when I started using
Visual Studio. I started appreciating Interbase more, when I started
using Oracle.

But admittedly, that's because a lot of concepts that were not explained
or even MIS-EXPLAINED in the Delphi world were elucidated in the Visual
Studio books.

But here's the entire take...

While in the Visual Basic world, it pays to be somewhat creative or
elegant or have finesse, that is absolutely not necessary in the Delphi
/ IBO / Interbase world.

All you need to do is have a DataModule and put in your database objects
there (Or if you like, you can have several Datamodules to be more
modular in your design. And when you get more advanced, you can use the
Remote Datamodules which are DCOM / Corba enabled).

Then, you have your forms, put in your visual components, use a
TActionlist so that you tie up all the possible operations on your form
(whether it be activated by the menu, the toolbar... whatever), place a
Datasource object to link in the desired Dataset in the Datamodule, then
you link the Data-aware grids and other visual components using the
Datasource property.

That's all.

After a while, everything gets pretty boring and routine.

Especially if you use IBObjects. You can even define your labels,
display titles, grid titles in your datasets so that when you put in
your IBO visual components, you don't have to reset the grid labels and
the formats. The same even goes with the look-ups.

My advise is, just go over the examples, step by step. Use the most
basic things you can understand, and go build your super-duper
Client/Server application.

If there is something you bump into, just fire a message to this list,
and you'll get your answer usually within the hour.

So, quit evaluating and just go do it.

NOTE: Those 30% components are enough to build your application. Don't
try to bite more than you can chew at this point. Grow into it.

With regards to Business Objects, I think you'll need to have a paradigm
shift.

Delphi is essentially a COMPONENT toolkit. And the Datasets are
essentially there to service the visual components (that is to retrieve
data from data sources in order to get them displayed), and I don't
think Delphi per se is here to be a data definition or analysis tool.

-- just in case there is an objection to this point --

For example, if you use Delphi as a design tool, you will be somewhat
constrained to have a single dataset object in your datamodule to
represent the physical table in the database.

That's possibly the worse thing you can do.

In Delphi, you need to conceptually tie up a dataset object NOT to the
physical table in the database that it represents, but rather to the
visual component that displays it.

For example, it pays to have one dataset for a visual grid and another
dataset to the same table to service a report object. Otherwise, you'll
find that your reports will skip over lines or puzzlingly repeat rows...
but that's because while printing your report, you moved your cursor on
your grid - if you use the same one and only dataset for both grid and
report.

---------------------------------------------------------------

Delphi wants application programmers to just plunk in the already
defined components in order to make applications. The FORM object is the
main VISUAL thing that delegates jobs to the components it contains.
While the DATAMODULE is the main DATA OBJECT thing that does the
delegation.

If you want to work with classes, you'll need another mind set and read
up on how to develop components in Delphi. If you make the components
themselves in Delphi that's the time you go into classes.

But Business Objects can be done. You can use Modeller or Bold tools to
do the job. With these tools, you can have UML with Delphi. But that
requires another learning curve that can suck you in and make you
unproductive. But let me add that if you get over the learning curve,
you'll find either of these tools to be indispensable once you
understand what they are for and how they are used.

Another thing, go into MIDAS only if you already get bored with C/S. By
that time, it will be fairly easy to do.

JUST BE SIMPLE, DIRECT, AND CLEAR in your approach to Delphi
programming.

(If I remember right, it is the 'EXTREME' programming way - you might
look this up in the web.)
----

Joseph Alba
jalba@...