How to create multiple found sets and single test for no found on all sets?

[Miss A!]

 

Hi there,

 

Can someone please help with script find situation, is it possible to create multiple find requests and have only one test for all finds to exit script if found count is zero? As in the case of the script below, even though the first search will return result, if there are no records in the last search, the script still exits, how do i control this properly?

Go to Layout [ “Console_Guided” (Console) ] Set Error Capture [ On ]
Enter Find Mode [ ]
Set Field [ Console::Tour_Start; Get ( CurrentDate ) ]
Set Field [ Console::Operator_Type; "Chamäleon" ]
Set Field [ Reservati::Final_chk; "Yes" ]
Perform Find [ ]
Enter Find Mode [ ]
Set Field [ Console::Tour_Start; Get ( CurrentDate ) ]
Set Field [ Console::Operator_Type; "Aclass" ]
Set Field [ Reservati::Final_chk; "Yes" ]
Extend Found Set [ ]
Enter Find Mode [ ]
Set Field [ Console::Tour_Start; Get ( CurrentDate ) ]
Set Field [ Console::Operator_Type; "Blue Planet" ]
Set Field [ Reservati::Final_chk; "Yes" ]
Extend Found Set [ ]
Go to Record/Request/Page
[ First ]
// Exit Script [ Result: Get(FoundCount)=0 ]
Loop
Copy [ Console::Tour_Nr ]
[ Select ]
Perform Script [ “New Invoice Record” from file: “TransportRemittance” ]
Go to Record/Request/Page
[ Next; Exit after last ] End Loop
Perform Script [ “Transport Invoice - Mail Current” from file: “TransportRemittance” ]

Thank you for our help.

 

[comment]

even though the first search will return result, if there are no records in the last search

 

No, that's not possible. You are doing:

 

Perform Find [ ]

Extend Found Set [ ]

Extend Found Set [ ]

 

If the first search produced a found set of 1 or more records, then it is not possible to end up with an empty found set as the result of extending it.

 

 

Probably unrelated to your question, but you can reduce the three find operations to a single Perform Find [ ] using three requests:

 

Go to Layout [ “Console_Guided” (Console) ]
Enter Find Mode [ ]
# FIRST REQUEST
Set Field [ Console::Tour_Start; Get ( CurrentDate ) ]
Set Field [ Console::Operator_Type; "Chamäleon" ]
Set Field [ Reservati::Final_chk; "Yes" ]
# SECOND REQUEST
Duplicate Request
Set Field [ Console::Operator_Type; "Aclass" ]
# THIRD REQUEST
Duplicate Request
Set Field [ Console::Operator_Type; "Blue Planet" ]
#
Set Error Capture [ On ]
Perform Find [ ]
If [ not Get ( FoundCount ) ]
  # HANDLE THE ERROR HERE
Else
  # PROCESS THE FOUND SET HERE
End If

Note also that hard-coding your operators names into the script is not good practice.

[comment]

Upon re-read:

 

if you were referring to this step in your script:

// Exit Script [ Result: Get(FoundCount)=0 ]

If you uncomment this, it will exit your script unconditionally. If there's no found set, the script result will be 1 (True); otherwise it will be 0 (False). But with either result, the script will be exited, unless you put this step inside an If[] statement as shown above.

[Miss A!]

 

Thank you Comment, your first response is solution - worked great!

 

Note also that hard-coding your operators names into the script is not good practice.

How do i get around this one, because the operator field is a value list - infact i do not know yet what is best practise and what is not, i am taking with whats working most times.

 

 

Upon re-read:

 

if you were referring to this step in your script:

// Exit Script [ Result: Get(FoundCount)=0 ]

If you uncomment this, it will exit your script unconditionally. If there's no found set, the script result will be 1 (True); otherwise it will be 0 (False). But with either result, the script will be exited, unless you put this step inside an If[] statement as shown above.

It is commented out because it is only working with the last request(the first request returns one record, the second and last return nothing and guessing its due to that the script exits even though there is a record(s) found with the first request) - Actually i was just doing something with the thought that i knew what i was doing.

[MikeKD]

If comment disagrees, follow his advice - I'm a beginner!

 

However, I think that it's best to create your value list from a new table of operators.

Then you can refer to all / some of your operators; maybe by selecting them in a global field created for the purpose.

 

 

Hope that helps,

Mike

[eos]

It would be beneficial to know what exactly you're actually trying to do – find “all tours that start today and have been checked” seems obvious, but where does the list of operators come from? Is this a subset of all operator(type)s, or is this the entire list anyway?

 

And why are you using names, instead of an operator(type) ID?

[Miss A!]

If comment disagrees, follow his advice - I'm a beginner!

 

However, I think that it's best to create your value list from a new table of operators.

Then you can refer to all / some of your operators; maybe by selecting them in a global field created for the purpose.

 

 

Hope that helps,

Mike

Thanx Mike, yes i would love to follow if only i knew how(how do i avoid hard coding if field data is drawn from an existing list or better yet, what is the alternative to hard coding?)..........the Operator name value list is using data from the Operator Name field in the Operators Table, that is right.

 

 

 

It would be beneficial to know what exactly you're actually trying to do – find “all tours that start today and have been checked” seems obvious, but where does the list of operators come from? Is this a subset of all operator(type)s, or is this the entire list anyway?

 

And why are you using names, instead of an operator(type) ID?

I have a layout with records for guided tours, from this layout i need to filter out the tours which are running on the current day, for those three operators and whose check box Final is marked, that means tour is running, i need that information to create an invoice on each vehicle used for the tour and mail the invoices to our Accounts department for payment processing. 

 

What is the advantage of using the ID dos, in this case all operator names are unique - Does using ID aid in anyhow to avoid hardcoding of the names or what will it really improve? I mean if using the ID's do i still not need to specify in the set field for which ID number i want to filter?

 

 

PS: The script is working fine already, ok - i suppose you are questioning for performance running, am i right?

[comment]

i need to filter out the tours which are running on the current day, for those three operators

 

Yes, but why those three and not the five or seven others? What makes those three special in this context?

 

 

i suppose you are questioning for performance running, am i right?

 

No, the reason to question this practice is that your script will need updating if one of those three operators loses their special status, or if another operator gains it. Such change should be performed only in one place - the Operators table, presumably - and all the scripts, calculations, relationships, etc. that use this distinction should inherit the change automatically.

 

 

What is the advantage of using the ID dos, in this case all operator names are unique

 

They may be unique - but they are not permanent.

[Miss A!]

 

 

 
Yes, but why those three and not the five or seven others? What makes those three special in this context?

Because an invoice amount need to be calculated for the vehicle used on this operator's tours without specifying specific rates for different seasons if the tour date range spans 2 seasons(High and Low Season) - If the tours starting date is on High season, calculate amount using the rate for high season even if it ends on say 2 or 3 days on a low season date.

 

 

 No, the reason to question this practice is that your script will need updating if one of those three operators loses their special status, or if another operator gains it. Such change should be performed only in one place - the Operators table, presumably - and all the scripts, calculations, relationships, etc. that use this distinction should inherit the change automatically.

 
 

 
They may be unique - but they are not permanent.

I am kinda getting lost on the ID part, well the names are unique and am specifying them individually in the set field step, I was still going to hard code the ID's if i have to perform my find on them(that is the operators do have a numeric plain serial value, Chamäleon = 2, Blue Planet = 3 and Aclass is 6) - So how do i do a find avoiding hardcoding values if i have an ID?

[comment]

What makes those three special in this context?

 

 

Because an invoice amount need to be calculated for the vehicle used on this operator's tours without specifying specific rates for different seasons if the tour date range spans 2 seasons(High and Low Season) - If the tours starting date is on High season, calculate amount using the rate for high season even if it ends on say 2 or 3 days on a low season date.

 

I don't see how that answers my question. Do you have more then three operators? If yes, what made you pick these three for this script, and not the others?

[Miss A!]

 

Because those three Operators are doing the most bookings and a special package price is calculated for them.

[OlgerDiekstra]

What Comment is getting at, is that one day, one of those operators will cease to exist, stop being special, or another operator will also become special. Just because something is true today, doesn't mean it will stay true tomorrow. Good practice means you allow for those changes to occur without impacting your coding.

You wouldn't hardcode the names of staff either (although my predeccessor actually did do that, and it's utterly stupid). People don't stay with the same company any more for their entire working life (ok, some do, but it's much less than back in very old days). People come and go. Your DB needs to be able to accomodate that.

So you create a table with operators and then use a boolean field as indicator that this operator is special. Then you find all operators that have that boolean set. A boolean field is generally a 1 (true) or 0 (false), but you can alos use a textfield with a value "special".

[comment]

Because those three Operators are doing the most bookings and a special package price is calculated for them.

 

Ah, now we're getting somewhere. I presume that "a special package price is calculated for them" is something that's recorded somewhere in your solution - is it not? So you could tell your script to start by finding all operators that have a special package price. And write them out to a list held in a variable. Only then go to the layout you want to search, and create a find request for each item on that list.

 

Of course, the items on the list should be the operators' IDs, not their names.

 

 

 

 

So you create a table with operators and then use a boolean field as indicator that this operator is special.

 

IIUC, the operator in this case is special because they have a related record in a SpecialPrices table, or something like that.

[OlgerDiekstra]

 

IIUC, the operator in this case is special because they have a related record in a SpecialPrices table, or something like that.

 

Not necessarily. One of my previous employers was a wholesale travel agency, and operators with special prices/discounts were all negotiated individually. So a special price/discount might just as well be stored in a discount field in the operators table.

It all depends on how business is done.

[Miss A!]

 

That helps my understanding a lot, thank you for clearing that part.......

[comment]

a special price/discount might just as well be stored in a discount field in the operators table.

 

That's entirely possible. My point was that they would be special because they had a "special price" property - not because they were marked as special. At least one would hope so - otherwise the same problem would arise, only in a different place.