Re: Modifying a record field value while not 'blocking' it to others

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.

Regards.
Remi-Noel
PS : I, also, make 'long' messages, isn't it ? :))

"Helpful Harry" <helpful_harry@xxxxxxxxxxxxxxxx> a écrit :

"Remi-Noel Menegaux" <rnmenegaux@xxxxxxx> wrote:

If you need to have changing data values accessible by ALL users in a
true "global" sense, then they have to be stored in a separate file /
table as NORMAL records. Usually developers have a "Preferences" (or
similar) file / table that has one record using normal fields to store
all the fully accessible data ... it also gets more complicated since
you have to add some 'error checking' to make sure the record isn't
already being used by someone else before trying to change the values.

Within the (long) post Harry just made, I pick-up the above paragraph, as
I
think the last sentence - starting with " it also gets more complicated
" -
may be easily overcome by just giving the user access to the one-record
in
using relationship to its fields, thus not 'blocking' the record while
letting him (the user) - if allowed - to change their values. That's why
I
think having a systematic one record file (table) to hold
'semi-permanent'
data is one of the developer 'good practices'.

I can't see how using a relationship can stop people blocking the
record (and therefore locking others out). I haven't actually checked,
but if someone is changing the record it should be locked, whether it's
being changed directly or via a relationship, otherwise FileMaker
doesn't know who's data to keep. ?:o|

No matter how you do it, it technically impossible to have two users
changing the same record (or maybe just the same field if the
relationship trick works) at the same time. Unfortunately the script
commands don't automatically wait and keep trying to access the record
if it's locked, so the developer has to create their own work-around.


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)


.

Relevant Pages

  • Re: Modifying a record field value while not blocking it to others
    ... And of course again the record you are trying to modify has not to be 'open' ... someone opens that ID=12 record everything in it is locked. ... often add a script line which opens a random record if the file holds enough ... system where customers use Credits when renting items and get Credits ...
    (comp.databases.filemaker)
  • Re: Stylesheet for My Sites
    ... customized thestylesheetfor the portal and WSS sites but don't see ... anywhere to modify the styles for all users "My Site". ... Opening a MySite in Internet Explorer opens that specific MySite in ... searching through the folder list in SharePoint ...
    (microsoft.public.sharepoint.portalserver)
  • Re: who to use fwrite to write through a hidden file
    ... It opens a file, and NEGLECTS TO SEE IF THE OPEN WORKED! ... You have no reason to assume this could work. ... Let me put it this way: I would not consider writing such a piece of code. ... how can you be trusted to modify something as critical as ...
    (microsoft.public.vc.mfc)
  • Re: Update a table using a form
    ... I have the form set up to modify a field in a ... >the record I want to modify. ... When the form opens it ... Access will open a VBA editor window with the Sub ...
    (microsoft.public.access.formscoding)
  • Re: linking record questions
    ... I have a command button which opens another form via macro. ... What is the proper way to link the records on that form to a control on the ... " How do I make the related field take on a matching value to the main form? ...
    (microsoft.public.access.formscoding)