× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I have to agree with Vern. I recently implemented a similar multi-field search where the search element may not be at the first of the field. Over a 7k customer list it's still sub-second response. Code snippet:

pos = %scan(%trimr(search):amname);
IF pos > *Zeros;
found = *On;
ENDIF;
IF not found;
pos = %scan(%trimr(search):amadr1);
IF pos > *Zeros;
found = *On;
ENDIF;
ENDIF;

It actually searches several more fields, but all in the same table record. If one has to deal with multiple tables, it could get a little hairier if one wanted to maintain some sequence/sort to the list.

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Friday, June 26, 2009 9:22 AM
To: RPG programming on the IBM i / System i
Subject: Re: Load a subfile with clients selected by user

David

If you go SQL, you would be better off doing it all with SQL - I'd say
use CHAINs or SETLL into the address file - if you have a logical over
postcode or the other fields, SETLL is enough to test existence and is
very inexpensive in IO and CPU.

You need several logical files, but you do, anyhow, to get good
performance with SQL.

SQL is not the answer for every situation, IMHO.

HTH
Vern

David FOXWELL wrote:
Hi, I have this tricky ( for me) problem.

We started off with a screen where a user could enter part of a client's name and a subfile would then be shown with those clients matching the name entered. We have a PF that contains clients that can be persons or companies. In that PF either client_name or company_name will exist for a client, but never both. A logical exists on company_name and another on client_name. Depending on the user input, the program decides which logical to read from. Recently, a third logical was created when the users wanted to search by maiden name.

Now, I've been asked to take into account zip or postcode, town and date of birth into the equation. As the addresses are in an adress file with an intermediate client/address file needed to get from the client to the address, it is obviously no longer just a question of adding another logical and reading from that.

It looks like a case for SQL. It probably should have started out that way but at the time embedded SQL was unknown ( to us ).

I was thinking of leaving everything intact, as I don't want to completely rewrite, but using SQL whenever one of the new fields gets used by the user. In that case, I'd use the user input to create cursors and use these to populate the subfile. At the moment the subfile is charged one page at a time and pagedown or up always reads from the PF.

If there are any flaws with this choice, maybe someone would let me know. I'm a little worried having never used a cursor to go backwards and forwards and to populate a subfile. The program will be continually opening and closing cursors with the same name. I think I need to manage when a user changes a field so that I don't close the cursor unneccessarily. Are there any issues to look out for when opening a cursor, say C1 for SMITH then closing C1 and reopening it for JONES of Birmingham, etc,etc.

I guess what I'm trying to say is am I at risk of any bad surprises given that I have not a huge amount of experience with such use of SQL?




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.