Jump to content

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


Miss A!
 Share

This topic is 2846 days old. Please don't post here. Open a new topic instead.

Recommended Posts

 

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.

 
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

 

 
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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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".

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 2846 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.