Is this a Flaw in FM ?

[Vaughan]

I'm beginning to think this is cold fusion.

[xoomaster]

I will try to repost my original script :

http://www.fmforums.com/attachments/uploads/1166060623-script.jpg

The fields with "_C" termination are global fields.

In the post above, I see no reason for the QD Charting 2004::Firstname to change ! Do you ?

Granted this works many times with no errors but out of 50000 records, 3 records had changed ?

Remember, I have the DB shared on a intranet with 4-5 users, on PC and mac . So it is not as easy as running a loop and seeing if there is an error ?

Also I have tracked the change back on the Audit trail with no specific abnormality otherwise ?

Remember please My question is if this has ever been noted by anyone, or is this product of sharing or intruption or other factors in my situation ?

Another reason I am interested is the fact that I have about 6000 field in this DB and there is always error with one field when importing to this DB, but I have not been able to figer out what and which field that is ?

[Genx]

How do you know your users didn't do this?

I.e. decided to try and think that your main layout was a search layout?

In any case it seems the purpose of this is to perform a find based on user defined values (entered into the global fields)... If the user entered data into the global field in the first place, doesn't the reasoned assumption come about that they expected that value to exist within the database in the first place and that in fact the reason they expected that value to exist within the database is not that the script accidentally entered it, but that they themselves made the entry?

[Oldfogey]

Xoomaster, to answer your original question, yes, I have seen many weird things like this happen with FMP. Script steps not working, calculations producing wrong results, buttons executing wrong scripts, etc. They have all turned out to be elves putting bugs in my scripts or field definitions.

If your 'Enter Find Mode' step was not working, you should have three fields corrupted, not one. Look elsewhere.

Are you absolutely 110% sure the data was OK to start with?

[aholtzapfel]

Is it shared using FM Server? The reason I ask is, How do globals behave in a Shared Environment? When hosted on a server all users can have thier own set of values in globals (Value in the field at start is the value that it was when the file was hosted.) If it is not hosted on a server isn't there only one set of values? Could your users be butting heads in the find script(more than one user trying to set globals at the same time)?

(I might be completely wrong, Just a thought)

[David Jondreau]

If your 'Enter Find Mode' step was not working, you should have three fields corrupted, not one.

Well played sir.

[Genx]

Omg, perfect time for a wiki: http://faq.filemakermagazine.com/index.php/Global_fields

[xoomaster]

The buttom line is the firstname is changing ! The user can search for what ever, but the First name should not be changing by this script.

Somehow the First name is earased completely !

About corruption of other field, only the first name field is changing ? this is also seen at the audit trail.

I do use File maker server 8.

And no the fields are not accessable for change on that layout .

I want to find if there is something that I can fix with the script or is it the DB ?

[Genx]

... why don't you add an extra little bit to your audit trail to tell you if a script is executing at the time?... I think you can do that.

[xoomaster]

The way the audit trail is set up, it shows only the field value changes, and not when a script is run, but I can send a start of script event to the audit trail. hopefully that would be enough to help me figuer out if it is the script ? The biggest problem is that it happens only once every 4 or 5 months, and we use the DB for probably 9-10 hours daily !

Thank you for the suggestion.

Edited July 25, 2007 by Guest

[Oldfogey]

Xoomaster,

You haven't told us why you are so certain that it is your script that is doing the damage.

Have you produced a DDR to make sure that nothing else touches that field?

[xoomaster]

You are correct, the field Firstname is not connected or used in any other relationships or settings that could cause it to change.

[Genx]

See, but at the same time - here's what i always say - computers don't do stuff by themselves - all they can do is flick switches.

In the same sense, I'm not sure that a FileMaker file would magically pick a field in a database and wipe it of its own accord.

[Oldfogey]

genx, I hate to disillusion you but computers do do things by themselves, especially when you mix them with complex software. The chance of a random error occurring is not zero. I'll be in Melbourne next week; you can buy me a bottle of port and I'll regale you with war stories.

In Xoomaster's case, though, the error is fairly clearly not random.

[Genx]

No really, lol. If you are using complex software, then its the badly written complex software doing it, not the computer.

A computer only "knows" how to flick a switch on and off and the best way to flick those switches and i'll maintain that for a long while to come.

I don't know about Xoomasters case... 500,000 times the script runs and 2 fields change at "random" as a specific result of that script running. I'd say it was just as likely a script chooses to malfunction 1 in 250,000 times (in what is likely a direct interpretation of base FM commands) as it was human error in the 9-10 hours the database is used per day. Not to mention that there is the possibility of scripts other than this one touching it or that this may be a multi-user environment where some other user changed a value and refused to say anything... and the audit trail (if the script why not the audit trail) stuffed up.

Oooooh well.