Re: Modifying a record field value while not 'blocking' it to others
- From: Helpful Harry <helpful_harry@xxxxxxxxxxxxxxxx>
- Date: Sat, 01 Apr 2006 11:39:12 +1200
In article <010420061134218446%helpful_harry@xxxxxxxxxxxxxxxx>, Helpful
Harry <helpful_harry@xxxxxxxxxxxxxxxx> wrote:
In article <442cee25$0$11400$626a54ce@xxxxxxxxxxxx>, "Remi-Noel
Menegaux" <rnmenegaux@xxxxxxx> wrote:
May I suggest you make a try ?
I assure you that - at least in FMP6 again, as I don't really know enough
about FM8, but I don't see why it should be different - you are not
'blocking' the record when modifying, from another record or from another
file/table, one of its fields through a relationship.
I'd bet my right hand on that, while, as always with me, I may be wrong.
Of course that record's field will be 'locked' the fraction of second in
which the actual modification is applied, but that's invisible to the user,
as it is effective only when you go out of the related field you just
modified.
And of course again the record you are trying to modify has not to be
'open'
ie 'seen' ie 'blocked' by somebody else at the same time.
As I am never 100% sure to express myself in english with sufficient
precision to avoid misunderstanding, let me take an example. Suppose you
have a 'Clients.fp5' file, with a record on Mr Martin with an ID = 12. If
someone opens that ID=12 record everything in it is locked. But if noone
opens this particular record, you may from another record or file, with
whatever relationship, show "Martin" in a related 'ClientName' field. If
then you change 'Martin' into 'Marteen', not only you can do that but it
will not block the ID=12 record, and someone else may change Mr Martin'
address that becomes 'Mr Marteen' address when you quit your 'ClientName'
field. All that because we say 'at the same time' which is not technically
neither right nor possible, but with 2 operations each one lasting 1
millisecond, you may see them as if they were done 'at the same time'.
This leads to the conclusion that you should never let the user see any
actual record, because then he would 'block' it to others, but rather let
him see what he wants thru globals (eg 'gID' in which he will write 12) and
related fields. As he has to be positionned in a record to see the layout,
I
often add a script line which opens a random record if the file holds
enough
records in it. With say 20 000 records the risk of conflict - ie 'blocked
record' - is small : I think that client of mine got the message 'that
record is blocked' 2 or 3 times in a 3 years of intense usage (10 users
almost 24/7 !).
By the way there are a lot of things you can do with all the files alive on
a network : modify or create a layout, modify or create a script, modify a
related value. The only thing you can't do when the bases are still open by
someone else is to open the Field Definition List and then modify a field
name or some part of its definition. I have used that facility all the time
for years without harming real time operations and I do it even from a
remote location using pcAnywhere in my case.
It would be very interesting to have someone do a real thorough testing of
that question to definitely close the subject.
All I can say at this stage is that I firmly believe in what I said above.
I realised after posting the previous message that I already have a
database that is used in a multi-user environment. It has a Credit
system where customers use Credits when renting items and get Credits
back if they return it early ... both via a relationship link.
Now if one computer is trying to rent a new item at the smae time as
another computer is processing the early return, then one computer was
running it's script but not actually changing the Credits total because
the other computer was already using that field / record. When this
happens Credits changes were being "lost". I had to purposely put in a
test to make sure the record wasn't in use before the scripts
continued.
BUT, it may well work if the users aren't trying to change the field at
the same time since it's not in use then, but during the actual change
the field obviously HAS to be locked from others altering it.
In you example, try clidking in the ClientName field on one computer,
start making a change, but DO NOT leave the field. Go to another
computer and try and access that same Client's ClientName field ... it
can't be done since it's in use (or there's a massive and dangerous bug
in FileMaker!).
This doesn't really matter for human users since FileMaker itself will
signal to them via the coffee-cup wait cursor and/or displaying a
message ... but a script command doesn't wait, it merrily continues the
script even though the command didn't process properly and you
therefore have to check that it can / has been done.
RATS!
I meant to say that the chances of two scripts hitting the same field
at the same time are minimal at worst ... but the chances of a script
and a human user hitting the same field are higher, especially for slow
or lazy users who don't exit the field very quickly.
Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)
.
- References:
- Re: Modifying a record field value while not 'blocking' it to others
- From: Helpful Harry
- Re: Modifying a record field value while not 'blocking' it to others
- Prev by Date: Re: Modifying a record field value while not 'blocking' it to others
- Next by Date: Re: Protect backup directory
- Previous by thread: Re: Modifying a record field value while not 'blocking' it to others
- Next by thread: Re: Protect backup directory
- Index(es):
Relevant Pages
|
Loading
