Re: [U2] Record locks (Unidata 7.2)
In the example below what happens to the lock? Does it release if the write is not executed? If not shouldn't you have a RELEASE statement at the end after the last END? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Saturday, 9 February 2013 3:57 To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) I should add that (in our test account) I switched to the READU statement along with a LOCKED clause - READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END I locked one of the records in the list I was processing. When the program was working on that record, the CRT statement was executed, and the program moved right along processing the rest of the list; and record I had locked was not updated. Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED (file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control things, allowing terminal input where the user can choose what to do about the record lock? I've decided to write the data to a new file, so this is no longer a big issue for me. If I had created the program using our vendor's tool kit, the generated code would have added all the appropriate gunk the system uses for record locks. The responses have been interesting as I've been looking for a chance to better understand how Unidata shops handle locks. Thank you, Jon Wells From: Tony Gravagno 3xk547...@sneakemail.com To: u2-users@listserver.u2ug.org Sent: Friday, February 8, 2013 2:30 AM Subject: Re: [U2] Record locks (Unidata 7.2) I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. From: Wjhonson I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users --- Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses,
[U2] : Evaluating DCOUNT
Hi Everyone, Does a DCOUNT get evaluated again for each iteration of a loop? Or is UniVerse these days intelligent enough to keep track of what's going on? e.g. for i = 1 to dcount(array,@fm) *commands here next i versus totalattributes = dcount(array,@fm) for i = 1 to totalattributes *commands here next i Apart from readability and perhaps easier debugging is there an actual internal difference? I know it was an issue on older pick releases but I cannot remember if it ever affected UV? Cheers Peter --- Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses, but advise you to carry out your own virus checks on this email and its attachments. We do not accept liability for any loss or damage caused by software viruses and do not represent that this transmission is free from viruses or other defects. Firstmac Limited (ABN 59 094 145 963) (AFSL 290600) --- ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] : Evaluating DCOUNT
The only way that this could not be an issue is if the compiler and the smarts and determined ahead of time that the array was invariant. My bet is solidly on plan b. -Rick On Feb 10, 2013, at 9:14 PM, Peter Cheney peter.che...@firstmac.com.au wrote: Hi Everyone, Does a DCOUNT get evaluated again for each iteration of a loop? Or is UniVerse these days intelligent enough to keep track of what's going on? e.g. for i = 1 to dcount(array,@fm) *commands here next i versus totalattributes = dcount(array,@fm) for i = 1 to totalattributes *commands here next i Apart from readability and perhaps easier debugging is there an actual internal difference? I know it was an issue on older pick releases but I cannot remember if it ever affected UV? Cheers Peter --- Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses, but advise you to carry out your own virus checks on this email and its attachments. We do not accept liability for any loss or damage caused by software viruses and do not represent that this transmission is free from viruses or other defects. Firstmac Limited (ABN 59 094 145 963) (AFSL 290600) --- ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] : Evaluating DCOUNT
If order isn't important for dcount(array,@fm) to 1 step -1 *commands here next i Should only have the dcount evaluated once on any platform/release I believe Ross Ferris Stamina Software Visage Better by Design! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rick Nuckolls Sent: Monday, February 11, 2013 4:53 PM To: U2 Users List Subject: Re: [U2] : Evaluating DCOUNT The only way that this could not be an issue is if the compiler and the smarts and determined ahead of time that the array was invariant. My bet is solidly on plan b. -Rick On Feb 10, 2013, at 9:14 PM, Peter Cheney peter.che...@firstmac.com.au wrote: Hi Everyone, Does a DCOUNT get evaluated again for each iteration of a loop? Or is UniVerse these days intelligent enough to keep track of what's going on? e.g. for i = 1 to dcount(array,@fm) *commands here next i versus totalattributes = dcount(array,@fm) for i = 1 to totalattributes *commands here next i Apart from readability and perhaps easier debugging is there an actual internal difference? I know it was an issue on older pick releases but I cannot remember if it ever affected UV? Cheers Peter -- - Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses, but advise you to carry out your own virus checks on this email and its attachments. We do not accept liability for any loss or damage caused by software viruses and do not represent that this transmission is free from viruses or other defects. Firstmac Limited (ABN 59 094 145 963) (AFSL 290600) -- - ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
