Values getting updated (released) to DB, need help in understanding the given scenarios

[Cringer]

So the solution is to make your transaction scope tighter.

 

[krishangopalmca]

So the solution is to make your transaction scope tighter.

I won't say making tight transaction scope is the solution, actually here its not about solution if we need to updated 4 or 5 or as many as required table in one transaction we have to.
And if we have to use 3 or 4 assign statements as per requirement we have to make use, but yes we can take necessary steps like using RELEASE statement so that other users can see all values or PAU indexed at the end.
But again have to code first looking at the logic/requirement.

Thanks all again..!!

 

[krishangopalmca]

I tried with indexed field, and found that whereever indexed fields will be assigned (doesnt matter 2nd, 3rd or 4th statement), all values till that assign statement will be avaialble in buffer, after that it wont till than it is released explicitly or transaction got over.
Strong scope is not impacting anything.


do for testtt transaction:
create testTT.
assign
F1 = "KG1"
F3 = "KG3".
assign
F2 = "KG2PUA". /* Indexed field PAU */
assign
F4 = TRUE.
pause.
end.

And its only taking care of Primary Index, not others.

It was a real time scenario for one of my code, a table was getting created in 2 different statements, first in include file with indexed and some date, time & user fields after create statement, second some specific values as per requirement without any conditions.
So when I was working on a defect, I was not sure whether exactly this code getting executed or some else, as only include file values were getting displayed in the buffer, but just after include file second statement values were not getting displayed. The only thing transaction was larger and was takin some time so I was able to get this situation.

 

[TomBascom]

Testing this sort of thing with temp-tables is another set of problems...

 

[krishangopalmca]

Testing this sort of thing with temp-tables is another set of problems...

Sorry for the naming convention, but its a DB table. I just created for all these kind of testing stuffs. ....

 

[TheMadDBA]

RELEASE just needs to be dropped from the ABL.... too much confusion about how it works.

The real key is this.... if you are inspecting newly created records from another session you need to be sure you can lock them or you WILL get unpredictable results. They call them dirty reads for a reason.

But the cleanest way is the way people have been suggesting... do all of your assigns for a record at once. It is faster and cleaner.