Is it possible for a "for each" or "find first" to lock an entire table ?
Example:
Section 1: For each tt-test where Id_test = 1
Section 2: For each tt-test where id_test = 2
Could someone tell me in which situation an Why one of these programs would show the message "User blocked registry SIN-41"?
The message doesn't look like a progress message, definitely not from the sample code you show.
Looking at the names of the buffer I suspect it is a temp-table,
temp-tables cannot be locked, they a private to your session.
if tt-test is a db table and ld_test is not the first segment of an index,
then all records in the table will be share-locked
As an aside: Attempting to lock temp-table records doesn't give an error and by doing so may future proof your code should Progress decide to introduce locking of temp-tables in the future.
Adding noise that the compiler should not allow (hello strict mode) and may do something (lock the record preventing it from being adjusted by who else exactly?) in the future... no thanks.
well.. Progress could update the use of no-lock on temp-tables to prevent updating the records yourself. A bit like the final keyword in java.
The problem is that you might want a compiler error and not a runtime error about that...
I agree with Stefan.
We disallow developers to add no-lock to a temp-table find because locking does not exist on temp-tables.
Progress will more likely never do such an update because it could break existing code of some customer.
I'm with Stefan and Carl. "locking" of temp-tables is conceptually a bit strange. If you need immutability you should come up with a different solution.
It was just a thought.
One more thing, if you think Progress wouldn't break customers code with an upgrade then you haven't been using Progress for very long - I can think of many but I've been here since V4.
One notable upgrade (think it was 8.1 to 8.2) was the font resizing when nearly every Gui screen had to be adjusted.
> We disallow developers to add no-lock to a temp-table find because locking does not exist on temp-tables.
What about VSTs? Their locks also do not exist. More over the most of VSTs can't be updated.
I'm using no-lock /and/ exclusive-lock with temp-tables as well as with VSTs. Am I wrong?
Don’t worry George, nothing wrong there… certainly not something to be catch by the strict compiler mode, nothing that can confuse the compiler nor other developers seeing it afterwards as it just makes clear your intention.
for each tt no-lock: assign tt.i = 2. end.
May be the future Progress versions will rise an error for the code above.
Strange as when I upgraded from 8.1 to 8.2 Progress we didn't change versions of Windows!?
Here are the facts:
1. Progress knew about the problems the version contained as it had a tool to try to fix the customer's code afterwards.
2. Progress claimed that V8.2 was compatible with Windows when it was released.
Luckily I came across a much better version of the fixing tool written by a Dutch guy which was almost perfect.
Shame Progress couldn't have matched the ability of that one bloke with their version rather than trying to blame the OS.
Some people might say that Progress has a world class DB but the UI was always it's rather ugly, backward, sister - but I wouldn't say this.
[quote user="cverbiest"]
We disallow developers to add no-lock to a temp-table find because locking does not exist on temp-tables.
[/quote]
I use NO-LOCK / EXCLUSIVE-LOCK on TTs to maintain a consistent coding practice for both DB and TT records and to communicate intent about what the code is intended to do.
IMO - the more consistent the code base, the fewer "rules" to remember, the better.
Hi Sidival,
That error looks like if you are blocking the register with the first for each. Try to do in this way;
Section 1: For each tt-test where Id_test = 1 no-lock
Section 2: For each tt-test where id_test = 2 no-lock
Regards.