Paul,
I missed this one too...
At 11:44 AM 15-04-02 +0000, you wrote:

>I have converted an application from BDE to IBO and am having a
>problem with getting the data in a TDBLookupComboBox to track the
>data in the undelying query.
>
>3 IB tables are involved
>SalesItems (SI), Categories (C) and SubCategories (S)
>
>SI contains fields CAT and SUBCAT (and other fields) which are
>populated by selecting values linked to the tables C and S
>
>Table C contains a field CAT (and other fields) and table S contains
>fields CAT and SUBCAT (and other fields).
>
>There are 2 IBOQueries
>SELECT CAT FROM CATEGORIES
>and
>SELECT CAT, SUBCAT FROM SUBCATEGORIES WHERE CAT = :CAT
>This query is linked to the first query by a TDataSource component.
>
>Both queries are selecting the correct information.
>When moving through the a query based on SI, the values of SI.CAT and
>SI.SUBCAT change. When SI.CAT changes, the TDBLookupComboBox linked
>to the SI.CAT field updates correctly but the TDBLookupComboBox
>linked to the SI.SUBCAT does not even though the correct values are
>fetched by the query.
>Sometimes the value displayed is correct but at other times (more
>commonly) the value displayed is blank. It is even possible to scroll
>forward through a record and the value to display correctly and the
>scroll back from the following record and the value to display as a
>blank.
>
>I placed an IB_Monitor component on the offending form and obtained
>the following output when scrolling from one record to the next. It
>is clear from this that the problem has been caused by the order of
>the SQL statements. The change in SI cause a change in SI.CAT
>from 'ZINTEC O/S' to 'ALUMINISED' and a change in SI.SUBCAT from NULL
>to 'AS04'. However the subcategories table is queried to locate the
>SUBCAT before the subcategories IBOQuery is updated, resulting in the
>error. In the BDE version of this program there is no such problem!
>Can you help me?

If I understand these relationships correctly, the salesitems is looking up
the categories; and sub-categories have to belong to a category, i.e. in
edit mode, you couldn't pick a subcategory independently of a category - is
this right?

So is it possible that the user has been able to pick categories and
subcategories independently - and thus you are seeing the blank
subcategories on cases where the relationship didn't exist between category
and sub-category?

Or, are you permitting these "mismatches" and creating new sub-category
records on the fly when the user creates a new combination?

If the relationships are as I think they ought to be - that the user may
select a category and then a subcategory from the subset of subcategories
which point to the selected category, then you need a way to eliminate the
possibility of the user selecting the subcategory before the category. For
example, trap the change to the subcategory column of the si query and
disallow it if category is either unassigned or it currently contains a
category that the selected subcategory doesn't belong to.

I would start by removing the where clause from the s query. The
datasource property of the s query should point to the c query - I presume
that it does, and you haven't accidentally latched it to the datasource of
the si query.... Because the linking column has the same name, you don't
need to go the parameter route: this is required when the key columns
don't match. The datasource will broadcast to the s query when the c query
scrolls.

How does the c query know about the value of CAT in the current si row?

Have you checked that your keylinks are pukka? Keylinks for the c query
should be CAT and, for s, CAT and SUBCAT.


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com