Hello all,
We have a temp table which is filled with data. Two indexes exist on the table , but no primary key.
Temp table =
DEFINE TEMP-TABLE w_CandidateRule
FIELD cr_Rule LIKE BillingRule.bru_Id
FIELD cr_DetectionOrder LIKE BillingRule.bru_DetectionOrder
INDEX cr_DetectionOrder cr_DetectionOrder
INDEX cr_Rule cr_Rule.
We fill up the temp table with data...
FOR EACH b_BCInstance
WHERE b_BCInstance.bci_Substitutable AND
NOT b_BCInstance.bci_Allocated,
EACH b_BRLineInput FIELDS (brli_BillingCode brli_Rule)
WHERE b_BRLineInput.brli_BillingCode = b_BCInstance.bci_BillingCode
AND NOT CAN-FIND(FIRST w_CandidateRule WHERE
w_CandidateRule.cr_Rule = b_BRLineInput.brli_Rule)
NO-LOCK,
{&JoinUnique} b_BillingRule
WHERE b_BillingRule.bru_Id = b_BRLineInput.brli_Rule
NO-LOCK:
RUN PrepareCandidateRule(BUFFER b_BillingRule).
END.
No by clause used....
Then, we have an open query command.
OPEN QUERY q_CandidateRule
FOR EACH w_CandidateRule BY w_CandidateRule.cr_DetectionOrder.
Field cr_detectionorder is the field which is not unique. (sadly and it is not feasible due to backwards compatiblity to change this)
Then we do a
GET FIRST q_CandidateRule.
What record will we get, is it the record that is sorted with cr_detectionorder, but what happens when we have two equal values, what is the second criteria : record that was first created in the temp table ? or another criteria ?
Thank you..
I can't answer your question, but..
Whatever that order is, you shouldn't trust it. If order is important, then you should explicitly set it, if not, then don't assume any.
That kind of assumption leads to very difficult to find bugs, specially when working with a mix of technologies.
I can't answer your question, but..
Whatever that order is, you shouldn't trust it. If order is important, then you should explicitly set it, if not, then don't assume any.
That kind of assumption leads to very difficult to find bugs, specially when working with a mix of technologies.
It is /probably/ the record with the lowest recid (emphasized the word 'probably' here) but that is the one that was first encountered in your for-each. Have you placed messages inside the for each loop to see what record gets added first? In different scenarios?
You should really do that, even if it was for fun, because like David said, you can't trust it. If there are no explicit rules for the order of the records, then they might change in a future version. Or they might behave differently on another OS. If you need a specific order, or if you just want to make sure they always have the same order, then enforce it by adding extra statements to the query.
If that is not possible, then I guess you will have to live with it....