Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM SQL » View Thread |
Messages 1 to 6 of 6 total |
[4.32] DELETE and record locked (in edit mode) |
Fri, Jun 15 2012 8:59 AM | Permanent Link |
Alessandra Romano | Scenario: two PCs shares the same table: the first goes in edit mode of
record #1, staying in edit mode for a while ; while the first is in edit, the second launches a "DELETE FROM sharedtable WHERE ID=1' trying to delete record #1. Well, the deletion succeeds, the record is removed, and when the first pc tries to post data obtains a "cannot unlock record" exception. Why ?! Any suggestion or workaround is appreciated. Thanks in advance. A. |
Fri, Jun 15 2012 10:29 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Alessandra
Are you using optimistic or pessimistic locking? Roy Lambert Roy Lambert [Team Elevate] |
Fri, Jun 15 2012 10:45 AM | Permanent Link |
Alessandra Romano | Roy Lambert, rischiando una denuncia penale, ha osato scrivere:
> Are you using optimistic or pessimistic locking? the default locking (pessimistic). -- Alessandra Ogni setta, di qualunque genere sia, e' uno schieramento del dubbio e dell'errore - Voltaire |
Wed, Jun 20 2012 11:11 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alessandra,
<< Scenario: two PCs shares the same table: the first goes in edit mode of record #1, staying in edit mode for a while ; while the first is in edit, the second launches a "DELETE FROM sharedtable WHERE ID=1' trying to delete record #1. Well, the deletion succeeds, the record is removed, and when the first pc tries to post data obtains a "cannot unlock record" exception. >> You should double-check your session's LockProtocol property and make sure that both PCs are using lpPessimistic. If that is the case, then the other problem could be that one PC is using an application whose DBISAM engine is set to use large file support, and the other is not: http://www.elevatesoft.com/manual?action=viewtopic&id=dbisam4&product=delphi&version=7&topic=Enabling_Large_File_Support If you mix an application that has large file support enabled with one that doesn't, then neither will "see" each other's locks and you'll run into issues like this. If you have any other questions, please let me know. Tim Young Elevate Software www.elevatesoft.com |
Wed, Jun 20 2012 11:48 AM | Permanent Link |
Alessandra Romano | > If you mix an application that has large file support enabled with
> one that doesn't, then neither will "see" each other's locks and > you'll run into issues like this. Thank you very much for your response, Tim. The two PCs were actually a physical pc and a virtual machine on VMWare player (on the same pc), the two copies of the exe running on each one, on the same shared folder (the virtual side used the VMWare "shared folder" system, not true windows folder sharing). Maybe *this* was the problem, i don't know for sure since i eventually solved the problem adding a "Locked" (BOOL) field to the involved tables. Nevertheless i subsequently had random dbisam 9217 errors on tables' refresh, and tables were NOT damaged, hence i guessed that was due to the weird "shared folder" thing. Then i tried to use a "real" windows sharing, and 9217 never happened anymore. So, maybe the first problem had the same cause, who knows. Alessandra |
Tue, Jul 3 2012 8:23 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alessandra,
<< Thank you very much for your response, Tim. The two PCs were actually a physical pc and a virtual machine on VMWare player (on the same pc), the two copies of the exe running on each one, on the same shared folder (the virtual side used the VMWare "shared folder" system, not true windows folder sharing). Maybe *this* was the problem, i don't know for sure since i eventually solved the problem adding a "Locked" (BOOL) field to the involved tables. Nevertheless i subsequently had random dbisam 9217 errors on tables' refresh, and tables were NOT damaged, hence i guessed that was due to the weird "shared folder" thing. Then i tried to use a "real" windows sharing, and 9217 never happened anymore. So, maybe the first problem had the same cause, who knows. >> Yes, I would be pretty confident that the problem was with the VMWare sharing not using proper network sharing that handled the Windows file API calls properly. If you have any other questions, please let me know. Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |