--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:

> Well, clearly, if there is no editing involved then a drop-down
> selector is no good to you at all.
>
> Master-detail wouldn't work, since the "master" in that

relationship

> is the table you want to look up. That would then require you to
> change the SP so that it would take the gl as an additional
> input; and each scroll of the "lookup" table would invoke the SP

for

> that gl code.
>
> I still don't see why you want the gl description in the UI. If

you

> want it in the report, it should be in the dataset. Some report
> tools let you define run-time lookups, though.
>
> If you want to avoid a run-time hit like "select description from
> accounts where gl = :gl" (which is what is behind the
> tib_lookupcombo) then pull all the gl codes and descriptions over
> into a stringlist before you run the SP for the report, using an
> ibcursor. Declare an internal stringlist variable and publish it

as

> a property, let's say fAccountList and Accountlist respectively.
>
> Initialise fAccountList somewhere, perhaps at FormCreate, and
> remember to destroy it somewhere!
>
> At whatever point you need to load fAccountList, call a procedure

to do it:

>
> procedure MyDM.LoadAccountList;
> var
> cr: tib_cursor;
>
> begin
> cr := tib_cursor.create(self);
> with cr do
> try
> ib_connection := YourConnection;
> ib_transaction := YourTransaction; // I keep a special
> "quick-hit" transaction for these uses
> SQL.Add('select gl, description from accounts order by gl');
> Prepare;
> First;
> fAccountList.Clear;
> while not EOF do
> begin
> fAccountList.Add(Fields[0].AsString + '=' + Fields

[1].AsString;

> Next;
> end;
> finally
> Close; // not essential, but won't hurt
> Free;
> end;
> end;
>
> Now you have a structure of strings consisting of NAME=VALUE, which
> you can refer to when your report wants the gl description.
>
> e.g.
>
> function GetAccountName(aCode:string): string;
> {pass in the gl code asString}
> begin
> Result := AccountList.Values[aCode];
> end;
>
> Even if I still don't clearly understand what the interface is

like,

> you can use this technique to hook up the stringlist to various
> controls and other structures that use stringlists.
>
> Just remember with stringlists that you have to take care of
> ownership so that the same Owner that creates them also destroys

them.

>
> Helen

Thanks again. That is the best programming tip I had had today. Right
on top. To clarify, this is purely a unidirectional traversing of
records for building a manual report, so no UI involved. A
combination of QR and textfiles, for some reason. I like your idea of
a "quick-hit" transaction to load the table values into a
Tstringlist. Now to be sure, I searched for "tstringlist limitations"
and somewhere someone says that tstringlist can handle up to 4 gb of
data. I don't know if I would ever or would ever like to load 4 gb of
text into tstringlist, but I guess that's enough to assure my
paranoid thinking. It won't hurt though to consider "what-ifs". Would
you like to comment on this? Thank you.