At 02:47 AM 10/03/2006, you wrote:

>OK, my program is doing well now with IBOObjects with the Tdataset
>equivalents. I'm not sure of my overall performance gain though as I don't
>have my IBO version set up with a beta tester yet. My laptop which is my
>development machine has a painfully slow hard drive and the first few reads
>and writes to the database have allways been slow and I haven't noticed a
>significant improvement there (although when I ran a side by side comparison
>there is definitely an improvement).

If you are using XP, make sure your database file does not have "gdb"
as its file suffix.

>Mainly I'm thinking I need to tune and tweek my database and I just got
>Helen's tome and hope to unlock that knowledge shortly.
>
>OK well I'd guess 85 - 90% of my application is non-data bound (I prefer to
>read and write directly to my user interface, I find it easier to debug
>problems, and also I find it easier to use make re-usable classes [such as
>TPatient, TInsurance, TEmployee, etc.] that take care of their own reading
>and writing to the database)...so anyway I'm not really tied to using the
>TQuery equivalents. Perhaps 50% of my queries are inserts and update...I
>basically have one select, one insert and one update for each of my classes
>
>So here are my questions:
>
>1) Will I get any significant increase by using other IBObjects? I'd guess
>I have 100-200 queries I'd have to convert I don't know what the priority
>should be to do that.

Yes. Let's establish some terminology here. The data access (DA)
classes are where the dividing line (such as it is) falls. The ones
starting with "TIB_" are "native IBO". The ones starting with "TIBO"
are what we'll refer to as "the TDataset classes".

>2) What IBObjects should I use for selects and inserts and updates?

The first thing I would do is go through the entire code (pas units
and DFMs) and find places where your SQL doesn't start with "SELECT"
or where it starts with "SELECT" but is designed to return a
singleton (single-row) result. Those need to be replaced with native
DA objects. As a rule of thumb, replace the first group with
TIB_DSQL, as it is by far the fastest, and replace the second group
with TIB_Cursor. If in doubt, use TIB_Cursor. It's simple to
replace it later.

For any multi-row selects that you want to display in VCL-compatible
controls, keep the TDataset DA classes.

For any multi-row selects that you want to process one-by-one, e.g.
to pass into a combobox or list control as items, use TIB_Cursor.

If you currently have TDataset multi-row selects that you want to use
for reporting using a report infrastructure that needs TDataset, keep
the TIBOQuery, or use AssignSQLWithSearch from a native dataset that
you are using for selections.

>3) How to convert them? Can I do a search and replace like I did with my
>original conversion from the BDE?

I don't recommend it *at all*. The BDE-to-TDataset conversion is a
breeze, since IBO's TDataset DAs keep the persistent field
objects. From bitter experience, getting rid of the TFields manually
is a mug's game. It is better *by far* to work through the objects
one by one, duplicate their functionality into a native object,
switch over to them and, when you are satisfied, completely delete
the TDataset object.

>4) What about switching even my few databound grids over the IBObjects
>equivalent, what of the performance and can I do a search and replace (like
>for the query and DBGrids)?

Again, not recommended. Deal with these groups of objects (statement
object, datasource and control) one by one. It's not such a big
deal, especially if you have your data and visual layers well partitioned.

>5) Also I kind of sort of have an idea about what Key Links does (well not
>really) but how important is it to performance to set that up?

It is ESSENTIAL and not just for performance. IBO needs you to
identify each row in a dataset uniquely. Under the hood it uses the
KeyFields structure for a lot of important things.

>Should the keylinks match the primary key exactly?

If the query involves just one table, then yes, and IBO will do it
for you if you have KeyLinksAutoDefine true. If there are joins, you
must have at least the pks of all of the underlying tables and you
may need to include more fields to achieve uniqueness.

Note, too, that you should replace all joined statements that use the
old SQL-89 syntax with the SQL-99 explicit join. Though IBO has some
extra properties to allow you to separate search columns from join
columns in an SQL-89 statement, you really need to hold your mouth
right. It's FAR better to do it properly from the outset.

> I wonder if I could write a little utility that processes my *.dfm
> files, queries the database for the primary keys and then enters
> the property values for keylinks?

As an exercise in futility, probably, be my guest! It would only
work for simple selects and IBO already does that properly for you, with KLAD.

Also (referring back to your first paragraph), if your database was
converted from a legacy Paradox database then your primary keys in
many cases will be useless and are probably one of the main
performance-killers. So, really, to avoid going repeatedly over old
ground, I'd recommend focusing on the database before you start doing
too much to the application. Get suspicious wherever you have PKs of
more than one column and *especially* where you have FKs of more than
one column (places where, e.g., you have master-detail relationships
where the links span multiple columns).

Helen