sonar-openedge
sonar-openedge copied to clipboard
Riverside-Software
Usage of default buffer for TEMP-TABLES
See: https://knowledgebase.progress.com/articles/Article/P133222
Using the default buffer for temp tables can lead to unexpected behaviour.
Do you have a short code example which reproduces the problem. The KB entry doesn't provide one.
Not as a small example, we had this in production code a few times. I can try to create a small example in the next few days if i find some time
Yes, please create a small example so that the rule could be documented. Based on the info in the KB I wasn't able to create one myself.
As far as i understand it, this is timing dependant. It all depends on when the AVM decides to Release the global buffer, so it don't even know if it is possible to create a case that reliably reproduces the error.
Do you mean something like this:
define temp-table tt no-undo
field i1 as int
field i2 as int
index ix is unique primary i2.
create tt. tt.i1 = 1.
message can-find( tt where tt.i1 = 1 ) view-as alert-box.
Seems to be a perfect example. Adding define buffer btt for tt makes the can-find return true.
@movedoa Do you confirm it was this kind of problem?
Yes it is this kind of problem. Although in this case, even if I define a local buffer, the message still shows no for me in 11.7.2. But if the message is in another scope, the definition of the buffer solves the problem. So at least this rule would kill some forms of this behaviour (And some other Pitfalls too)
I probably mixed things up this morning, as I can't reproduce anymore (I also tried to verify earlier the behavior with DB tables). Defining the local buffer doesn't help, I'll ask on communities (or to TS if nobody answers there).
It helps if you release the buffer before the can-find It also helps if the message is in a different scope (while it can still happen there when using the default buffer)
I am not sure how important it is to reproduce this (if it is even possible to do reliably) Generally i consider it best practice to don't use default tt buffers anywhere since it prohibits a number of problems that global buffers greate. This is just one example.
I wonder, when programmer creates a buffer on the same scope as the default buffer, and then creates/assigns that buffer instead the default buffer, would the problem not be the same? The problem as far as I understand is not that you are using the default buffer but that you are using a buffer with a very large scope. However, using a buffer with a large scope is not wrong either, it is even convenient when different fields of the temp-table are assigned by different methods/ip's/functions. It only involves the risk that the record is not available yet, so what you really should try to scan is wether there has been any circumstance that has forced the record to be available , like release, or assign of a non-default index field value. What I am really trying to say is: if you warn for using the default tt buffer, then it is important that you can mark the source such that the warning is suppressed.
After the post on communities, I remembered that CAN-FIND in fact uses another buffer name. So I don't think scanning for default buffer usage on TT will really help. What has to be reported is when a TT record is created and that another buffer (and can-find implies another buffer, even if the name is identical) looks for this same record within the same transaction scope.
Ok fail enough, but i think not using the default buffer at all still has its values. So this would be a different rule then.
I consider global buffers a bad practice in general since, for example, a query in my scope should not change behaviour of other program parts, which it can do with global buffers, but it can not with a locally defined buffer. I can be very error prone in big applications especially in legacy code that relies on a specific buffer state at a specific time. With strict/sane coding standards this would be no problem, but in the real worls with 20+ year old code this can be a huge pain.
@movedoa Yes, there can still be a rule for default buffer usage on TT. It's just the explanation doesn't specifically relates to the initial KB entry.