At 12:14 AM 13/11/2003 +1000, you wrote:

>Hello,
> I've been playing around with IB Objects lately, evaluating it
> for an up and coming project. Once you get past the shock factor
> of the x number of properties and realise there's an in-built
> component editor, things start looking a little better! :)
>
> Anyway, to keep in-line with minimizing network traffic, I'm
> planning to have browse screens with grids containing maybe 2-5
> columns containing some useful information for the user to pick
> a particular record to view the details of. The actual detailed
> view of the record may contain 20 odd fields for editing/adding
> or perusing.
>
> So, I have a basic query for the browse screen such as:
>
> SELECT BuyerCode, BuyerName
> FROM Buyers
>
> My question is, once a user selects a record to get the details
> for, is there a smarter way of getting the other details for
> that record (for adding/editing/browsing) than having a second
> query's MasterSource set to the first query and executing a
> query such as:
>
> SELECT * FROM Buyers
> FOR UPDATE
> WHERE BuyerCode = :BuyerCode
>
> Is this the way to go about it, or is there some "magic" that
> IBO has?

Well, first, for a selector list you wouldn't do a SELECT * query
normally. As a diehard pedant, I won't ever use select * except if maybe
I'm chucking a quick test app together.

Master-detail is ideal for this kind of 1:1 relationship if it's a big
table. If the BUYERS table is only small, say less than 200 rows all up,
you can use the same dataset for both the selector and the detail. Use a
single datasource and link both the selector grid and the detail controls
to it.

Native IBO has all the magic for master-detail. The TDataset components
follow the BDE rule: you need to use parameters for the detail set if the
detail's foreign key has a different identifier to the master's PK. If
they match, you don't need to refine the query with a search clause because
the component does the magic for you via the Datasource property.

Native IBO does the magic regardless of whether the key identifiers match.

> I've come from the crude BDE background of SELECT * FROM table,
> and only show the particular columns in the grid.

In client/server, focus hard on not pulling stuff across the wire that you
don't need. Just get the key columns and those other columns that you
actually need, and always use a where clause to limit the rows you fetch.

In native IBO, the datasets drive the controls, so you set up all of the
grid properties in the dataset and the native grid has no Columns[] object.

Helen