harbour lock function

[l3whmg]

Hello to everyone.
I need your help to better understand the operating principle of the LOCK function.

I found that, within the same process or within the same thread of execution
of a program, LOCK does not seem to work well when I perform LOCK, on then same record, more than one time: the record is always LOCKED. If I run the program more than once, the LOCK works well.

Example.
Case 1 - process A function 1 LOCK a record; process B function 1 try to lock the same record, but fails: proper operation
Case 2 - process A function 1 LOCK a record; process A function 2 try and lock the same record: malfunction

I enclose a simple program to test.
- Run the program twice separately and act only on the first button: good operation (Case 1)
- Run the program once and act on the two buttons: operating doubt (Case 2)

I believe that the need to lock the same record (for different reasons or functions) within the same process, is an event not to be overlooked.
It 's just my problem or misunderstanding or should be reported to the developers of Harbour compiler?

Many thanks to everyone.
Best regards

[l3whmg]

Hi guys,
is there someone can help me about this ?

Many thanks in advantage.

[Rathinagiri]

Hi Luigi,

I am not well versed with LOCK functionality.

Hope Esgici or others help you.

[esgici]

Hi Luigi

Sorry for delay

My last days past with some hardware (and sofware) and health problems. Moreover your .zip file doesn't contain .dbf file to test. Afterward I'm noticed it builds their own table, so I'm here

Dear Luigi

Your expectation seem reasonable. But I'm thinking that "re-locking" a record already locked doesn't have any problem. Even may be useful under some circumstance. Importance is ACCESS, others than have posed lock, must can't access a locked record.

And this others also important; other users, other applications etc. Does other procedure / module in the same application included restricted things? IMHO no, you may lock a record in one procedure and edit it in other one.

In summary, IMHO the behavior of our compiler is reasonable and correct.

I hope that this explanations will help you.

Regards

--

Esgici

[Rathinagiri]

Thanks for the explanation Esgici and I pray for your well being.

[l3whmg]

Hi Esgici,
many thanks for your replay, I understand what did you write and I are in (general) agreement with you.
Is a fact that I realized a few days ago, being able to operate with more forms in a program written with HMG.

The case involved a table containing the progress to assign: while maintaining the record locked in a form, I could assign a new number (other table) unless the record is locked. This situation has me a little especially thinking about solution much more complex than mine .

Of course that the same user lock a "progress", which will use in other applications, is an unusual case.

Any way, thank you very much again for your invaluable help.

Best Regards.

[esgici]

Thanks Rathi; we always need prays of our friends.

Regards

--

Esgici

[esgici]

Hi Luigi

What happy times was that DOS days, DOS and Nowell days

For testing a multiuser application we have need a real network; more than one PC, ethernet cards, hubs, routers, cabling etc ...

Now its very simple : run more than one instance of your program and test whatever you want.

Did you tried your TestLock by this way?

I did, and IMHO it run exactly what you expect.

Regards

--

Esgici

[l3whmg]

Hi Esgici,
of course
I've tested this program with my little LAN and (on the same PC) I run the program more than one instance: It's work fine like I expected

What happy times was that DOS days, DOS and Nowell days

Yes

What do you thing about the famous Plug&Play or MsWin .dll and register (installed, update, reinstalled, reupdate and deleted....and so on by every program you want use) ?

But behind all of this there are programmers (human)

[l3whmg]

Hi Esgici,
I'm sorry for my ignorance But why is not there a "DataBase" based upon dbf technique?
We have MySql, PostGreSql, etc. Why Not?

Best regards