What code do you like the most, left or right? See screenshot in link below:
Please elaborate why? I'm very interested in the answers.
Apart from the fact that the right hand one won't work (not all references to Company have been updated), I think the left is better. It's good practise to do your updates on a buffer with a strongly scoped transaction block, but using buffers elsewhere isn't necessary.
My opinion of course.
Your opinion is wrong ;)
Because this is an internal procedure you very much want to use a buffer scoped to the IP. If you just allow "free references" willy nilly you will be elevating the scope of the default buffer to the procedure block and causing unintended side-effects. Even if all you do is NO-LOCK reads this is a bad thing.
My preferred approach is to include buffer definitions such as:
define buffer customer for customer.
for all of the tables referenced in an internal procedure. This ensures that no accidental side effects occur due to unintended references to the default buffer. Of course you should also define a distinct "update" buffer and use strong scope for any updates -- that's a second buffer.
BTW -- the "buf" prefix and other junk (like "l") is hideous. Cluttering up your names with noise about the datatype makes your code unreadable gibberish.
FIND FIRST to find a unique record is also an abomination. Suppose there are two or more companies meeting your criteria? Why aren't you dealing with the rest of them? Or at least throwing an error that there should only be one? Why is the one that you just found magic?
I disagree with this. If you know that the records are unique and a FIND will never return more than one record then FIND FIRST will actually save you a wee bit of time because the ABL doesn't have to do its check for duplicates (i.e. the AMBIGUOUS function). Outside of that corner case you are correct.
Nope. This is how it works and the info came straight from Mary Szekeley's mouth. By default we do what we need to do to determine if AMBIGUOUS should return true/false and by using the FIRST phrase you are telling us that you don't care about ambiguity so we don't do the work.
By the way, we are talking about nanoseconds here so for most people it won't really matter but for those who need to remove every unneeded nanosecond this will matter.
With all due respect I think you are perpetuating a myth. There is no check for ambiguity on a unique find -- I have never found an iota of evidence to support that contention. If the FIND is using a unique index there is no need to check anything -- the very nature of the index ensures that. If it is *not* a unique index then you should be using a statement that deals with multiple records such as FOR EACH.
Even if I am wrong (I'll happily buy you lunch if you can show that I am) -- the statement is still misleading the next programmer to come along and, in my mind, the downside of misleading code far outweighs any hypothetical minuscule saving of execution time. FIND FIRST is waving a flag saying that there could be multiple records -- but then doing nothing about the possibility.
BTW, I've talked to Mary about this too -- and I didn't hear what you heard. Maybe we asked slightly different questions?
It came directly from the person who wrote the code. I stood in her office while she explained it to me many, many years ago.
I am sure there are optimizations in the code related to the ambiguity check to make it as efficient as possible so it is likely it can detect the 'perfect scenario' and just flag ambiguity as false but I do know that it is possible that a second read has to be done to satisty the ambiguity check.
It's my understanding that this behavior has never changed (i.e. horse left the barn long ago).
I update the screenshot, I think all references are ok now. Thanks for noticing my quick copy paste mistake.
Like I said, I've asked Mary about it too. I didn't video the conversation so I have to rely on my pitiful wetware capabilities but my recollection is that she said that a UNIQUE FIND with a UNIQUE index does NOT check for ambiguity. What would it even check? Maybe we can invite her to drop in sometime and we can have a spirited discussion :) Or maybe we can get some of the current engineering people to weigh in on what the current code does.