Hi Helen,

thanks for direction and suggestions.

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

The selector query was the:

>> SELECT BuyerCode, BuyerName
>> FROM Buyers

but yes, I agree.

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

hmmm, but if you wanted say 4 fields displayed in the selector list
but 20 fields displayed in the detail record view, then don't you have
to use two datasets as the displayed fields are dependant on the
dataset and not the grid? As you pointed out:

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

cheers
Mark


Thursday, November 13, 2003, 1:05:59 AM, you wrote:

HB> 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?

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

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

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

HB> 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.

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

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

HB> Helen






HB> ___________________________________________________________________________
HB> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
HB> without the need for BDE, ODBC or any other layer.
HB> ___________________________________________________________________________
HB> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
HB> keyword-searchable FAQ, community code contributions and more !

HB> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/