| Argument passing - Subroutines and Functions - Mike Pope |
| Caching in on the Frames Array - Mike Pope |
| QTIPS - Fast Dynamic Array Building |
| Networked %SK% |
| RTP Series - RTP25 |
| A RevTechie Replies - And Miscellaneous Jottings - Mike Pope - Revelation Technologies (UK) Ltd |
| Playing with Scan Codes |
| QTIPS - Compiling Protection Code |
| QTIPS - Invalid Code and Command |
| QTIPS - Code/Command Help |
| Compiling 64K on a Shoestring by Blaise Wrenn (LexStat Systems Ltd) |
RevMedia FKB
| Document | V3I5A11 |
| Title | Uncommon Knowledge - WC_Joined_Locks% |
| Keywords | WINDOW_COMMON% WC_JOINED_LOCKS% |
| Text | @FM delimited array of record keys which have been successfully locked by the window Note that this does not include the name of the table the lock was on Note further that if any of the attempted locks fail (WC_WLOCKED% = 0 and WC_Joined_Keys%<13> = "") that this array will still contain all successful locks up to this point Thus is an attempt was made to lock F1 F2 F3 and F4 and the lock failed on F3 WC_JOINED_LOCKS% would contain F1 and F2 As of 2 1 this is the cause of a problem in expected behaviour when the window is exited Since the window was unable to lock all needed records it seems to overlook the fact that it has been able to lock some Thus when escaping FROM a window those records in WC_JOINED_LOCKS% when WC_WLOCKED% is 0 will remain locked To avoid this simply code a post application to check whether all of these values have been unlocked (Volume 3 Issue 5 Page 14) |
Page last modified: 31/01/03