PDA

View Full Version : DFFILE: client atomic vs. server atomic



Joerg Thuemmler
27-Dec-2005, 08:52 AM
Hi,

we use df 3.1d on linux (kernel 2.4.19 actually), our users connect
as terminal users on the box (ssh), all databases and programs
running on the server box. Last time I had some seldom lock
problems, like a deadlock stopping most users work. Other was a
get_current_lockcount not 0 where it should be (and in 1000s of
cases is). Today the following construction failed (a little bit
simplified):

....
autopage sc1
name today artnr menge ...
...
clear p502
sysdate4 today
entermode
ARTIN:
entry pa21.artnr artnr {autofind}
[not found] goto ARTIN
entry 0 menge
endmode
gosub GETNR // gets unique number nr
reread pa21
calc (pa21.menge+menge) to pa21.menge
move today to pa21.lastdate
save pa21
move nr to p502.nr
move menge to p502.menge
move today to p502.budate
save p502
unlock
....

after running this (working a million times) p502 record was written
correctly, but no changes were made to pa21!
If there was a finding problem, so how autofind did work but reread
didn't?
I can't see any way to produce this, repeating gave the correct
behavior (p502 record written, pa21 changed). Lurking into several
directions i found the possibility to set transaction type in dffile
but no explanation in my users manual, this selection doesn't appear
in the "dffile" section at all and the explanation on client/server
architectures is poor.
Who knows the use of this, does it have any influence on a terminal
servers system?

Some other ideas to explain the above errors?

thx for any help...

joerg

Vincent Oorsprong
27-Dec-2005, 12:45 PM
Joerg,

Are you sure that the REREAD refinds the record you want to update? Is the
table not readonly (DataFlex and/or O/S)?

Your code is not how I would write programs but further doesn't look wrong.

Did you check the 3.x documentation on the transaction property/setting. It
should be discussed.

--
Regards,
Vincent Oorsprong
Data Access Europe B.V.
http://www.dataaccess.nl
Tel: +31-74-2555609

Ben Weijers
27-Dec-2005, 02:22 PM
Basically, if you use Linux and the Embedded database you cannot set this
attribute it will always be client atomic. The server atomic setting used to
be supported on Netware file servers using Netware's transaction tracking.
The behaviour you describe is not the result of setting this table
attribute.

Regards,

Ben Weijers
Data Access Worldwide

Joerg Thuemmler
28-Dec-2005, 01:56 AM
Ben,

thanks, I can indeed set it for what I want - just in this moment I
set it to nothing, both deselected. I can't decide wheather the
setting has any influence on used transactions but until now I don't
use this. Maybe it's of some interest to play around with it and to
rewrite some code using transactions.

Vincent,

Most of my code is elder 2.3b code and I tried to cut out all what
has not to do with the question of locking and saving. I should have
found the article on transactions myself, thx, it gives some clue on
what is possible using them.
The table is of course not r/o, as I told, the code did work a
million times and is after that one case working properly either. My
idea is that some locking problem caused this behavior, because
the record was found before - autofind had to set [found] true - and
reread is only done to reflect changes some other user might have done.

thx

joerg

Ben Weijers wrote:
> Basically, if you use Linux and the Embedded database you cannot set this
> attribute it will always be client atomic. The server atomic setting used to
> be supported on Netware file servers using Netware's transaction tracking.
> The behaviour you describe is not the result of setting this table
> attribute.
>
> Regards,
>
> Ben Weijers
> Data Access Worldwide
>
>