At 08:25 AM 17-10-01 +0000, you wrote:

>Hi,
>
>With two tables, PROGRAMS and TALKBACK (live radio shows) as follows:
>
>PROGRAMS
>
> LANGUAGE
> PROGRAM
> LANG_NAME
> PROGRAM_NAME
>
>TALKBACK
>
> PROGRAM
> DATE_CALLED
> NAME
> SEX
> AGE
> LOCATION
>
>On form create, the list in the TIB_LookupCombo is resolved by a
>TIB_Query (IB_Query_Programs), with SQL
>
> SELECT PROGRAM, PROGRAM_NAME FROM PROGRAMS where language =
>'TGL'.
>
>There is an OnChange event in the TIB_LookupCombo which executes
>another query as IB_Query_Talkback.Open;
>
>The SQL for _that_ query is "SELECT * FROM TALKBACK where PROGRAM =
>'PEW'. This is displayed in a TIB_Grid
>
>It all works fine, the rows for PROGRAM = 'PEW' are displayed in the
>TIB_Grid correctly. Now I want to take it one stage further (I'm
>learning), and pass a parameter (or similar) to the TIB_Query
>(IB_Query_Talkback), so that the 'hard coded' SQL (PROGRAM = 'PEW') is
>set to the PROGRAM from the TIB_LookupCombo.

You could do it generically at all "phases" of your program by using parameters in place of your hard-coded values, e.g.
SELECT * FROM TALKBACK where PROGRAM = :program

In situations where only the value changes (not the query itself) this is ideal, because the dataset does not have to be reprepared each time the value changes.

However, if you are needing to change the entire WHERE clause in response to certain actions (as seems evident here) then make use of the SQLWhereItems property of the dataset and apply them in the OnPrepareSQL event. (A change in the SQL always invokes a fresh Prepare). Your "base" statement would then be simply SELECT * FROM TALKBACK. In the handler you can apply both the SQLWhereItems and the values.

SQLWhereItems is fully documented in the Help. There are also several references for it in the online FAQ.

>Resulting in a TIB_Grid display change, when the user selects a
>different program from the TIB_LookupCombo. How do you do this ? No
>doubt because the SQL is a property setting, I just change the
>property for that object, but where do I do this ?

Changing the entire SQL property is a last resort and should be avoided, since IBO has full support for altering criteria at run-time with minimal overhead.

>PS What conventions should I use when describing objects ? For
>example if it is a TIB_Query, with a name of IB_Query_Programs, is
>TIB_Query (IB_Query_Programs) suitable ?

Each to his own...unless I am doing an application where I will have TIBOQuery and TIB_Query objects in the same datamodule, I just use the prefix 'q' on the table name or a meaningful string that says something about the content of the set. My own prefix convention is 'cr' for TIB_Cursor, and 'ssp' for select stored procedures, 'xsp' for executable stored procedures and just 'x' for TIB_DSQL. I name all datasources by replacing the dataset's prefix with 'ds'.

>What about connections, tables and query names, what conventions do
>people follow ?

As brief as possible! I follow Jason's style of using 'cn' for the connection. I usually just use 'tr1', 'tr2' etc. for the transactions. I never never never use tables so I don't have a convention for them.

cheers,
Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________