... or there's some substantial differences?
/* Trovare le righe d'ordine associate all'ordine dell'ultimo cliente nella tabella del DB */
FIND LAST customer.
FOR EACH order, EACH orderline OF order WHERE order.custnum = customer.custnum:
DISPLAY orderline WITH FRAME a TITLE "MODO 1".
FOR EACH order
FOR EACH orderline OF order WHERE order.custnum = customer.custnum
DISPLAY orderline WITH FRAME b TITLE "MODO 2".
FOR EACH order WHERE order.custnum = customer.custnum, EACH orderline OF order
DISPLAY orderline WITH FRAME c TITLE "MODO 3".
run with DB Sports2000
Well, you get the same data in return.
But the FOR EACH, EACH ... is just one loop, one block, one default error handling etc.
FOR EACH ...:
FOR EACH ...:
Creates two loops. You can do processing before entering the inner FOR EACH and after the inner FOR EACH. An error in the inner FOR EACH does not neccessarily undo the outer for each and so on.
Give's you more flexibility, while the first might be a little more efficient when running big result sets (block statements and looks are rather expensive ABL statements)
Since your sample uses DISPLAY statements, the default FRAME behavior is also scoped to each FOR block.
Even when you get the same result, there is a difference in style. Putting everything into one FOR EACH appeals to some people, but can be hard to read unless carefully formatted. If there are other conditions not in the FOR EACH, it can be clearer to test all conditions inside the block. There are times one wants to do a NEXT before executing the inner block. Etc. I.e., they can produce the same results, but they certainly read differently and it is possible to do different things with each form.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
difference in style. Putting everything into one FOREACH appeals to some people, but can be hard to readunless carefully formatted. If there are other
difference in style. Putting everything into one FOR
EACH appeals to some people, but can be hard to read
unless carefully formatted. If there are other
Well my preferred way of coding is that readability is no conflict to better performance. If properly formatted, a big FOR EACH (including comments insided the statment) keeps as readable as nested FOR EACH blocks.
test all conditions inside the block. There aretimes one wants to do a NEXT before executing theinner block. Etc.
test all conditions inside the block. There are
times one wants to do a NEXT before executing the
inner block. Etc.
That's what I meant with more flexibility.
When it comes to just count the number of orderlines for all orders with certain given criteria (on the order), there's no doubt for me, that one for each is the only way to go:
FOR EACH Order WHERE ... NO-LOCK,
EACH OrderLine WHERE OrderLine.OrderNum = Order.OrderNum NO-LOCK:
i = i + 1.
Just to go against the grain, there may be a difference in the records available.
If you put code in the outer block, but not in the inner block, you'll also get the order records that don't have order-lines.
In this particular example, there'll be no difference, but there may be.
But if ABL is a 4th generation language the engine of ABL don't must optimize the sequence of for each it self?!
The ABL does not so any statement optimization at all. The closest that it comes is logical expression "short circuting".
ABL queries are optimized at compile time following some fairly complex and possibly incompletely documented rules that can be found at http://www.peg.com/techpapers/monographs/selection/selection.html
As the other posters have already pointed out, there's a very substantial difference between nested for eached and multiple for each, each.
The main difference is the the fact that a nested for each does an outer join of the data, while the multiple for each, each does an inner join.
If you have a for each on customer and a subsequent for each on the orders of a customer the difference between an outer join and inner join is that:
- The outer join (implemented with a nested for each) will return all customers
- The inner join (with the multiple for each) will return only the customers with orders
In your examples you may skip orders of the selected customer that don't have orderlines if you use the multiple for each (inner join).
Looking at your code, I must point out that the where clause on the order should be part of the for each order. So your code:
FOR EACH order NO-LOCK /* ALWAYS SPECIFY LOCKING CONDITION */
WHERE order.custnum = customer.custnum:
FOR EACH orderline NO-LOCK OF order
In your example code you are reading all order records and not just the ones related to the selected (last) customer.
Finally a personal note, the questions you're asking to the forum are quite basic and I'm sure you have collegues near you with more experience that can answer them in just a minute (and in your native language )
No pun intended!
]]>Finally a personal note, the questions you're asking to the forum are quite basic and I'm sure you have collegues near you with more experience that can answer them in just a minute (and in your native language )No pun intended!
exercise to write/read/understand in a other language for me that don't have lot money for travel is a method for don't forget a language. Already tried with spanish language and i forgot it;
i think that the incoming of the Web2.0 and it potential istrument like forums, RSS or a social networks rappresent a possibility to gain knowledge;
last but non last, here remain track for user that will arrive after me, and topic like the mine (anche se scritti in inglese pessimo) should be usefull to them.
If the comunity don't like my behavior i'm sure that they will not lose time to tell me.
è stato 1 piacere conoscerti in PSDN.
If the comunity don't like my behavior i'm sure thatthey will not lose time to tell me.
If the comunity don't like my behavior i'm sure that
they will not lose time to tell me.
I'm pretty sure that Wim and others are just trying to find the best ways to help you getting the fastest possible kick-start with ABL and the Progress tools.
From my end - you and all other beginners are welcome to ask any question! The ABL needs a more wide spread community!
]]>I'm pretty sure that Wim and others are just trying to find the best ways to help you getting the fastest possible kick-start with ABL and the Progress tools.
... as man of science there's sometimes that i think in my mind "why it work" and no non "if work i'm ok", so the curiosity and the desire to explore push me to create bizarre post, but is my personaly way to explore a programming language, or programming environment, designed with a specific purpose in mind, such as the development of commercial business software.
In my office it is not so.