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.

Alessandra


Are you using optimistic or pessimistic locking?

Roy Lambert Roy Lambert [Team Elevate]

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

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

> 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

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