Is this a Flaw in FM ?

[xoomaster]

In many years of using FMP and designing FMP DB, there has been probably a handful of occasions that somehow a script step is scaped and not implemented as expected. One of the very basic example of these occasions, is when FM is asked to enter a "Find Mode" and suddenly finding the script in browse mode instead, scaping over the request ?? and as a result unwanted results is encountered.

I have very carfully studied this process and there seem to be no other explaination.

I use FMP in multi-user environment with mix of PC and MAC and FM Server 8.

Any suggestions ? Now I now that I can always use an "If" statement to make sure I am in "Find" mode, but I am interested in what actually may be the problem.

Thank you in advance.

Xoomaster

[IdealData]

I have experienced similar when switching layouts during script execution. In fact it still exists in one place and I tried test the current layout name but this had no effect. My setup is similar to yours and I suspect there is a file corruption - but mine does not cause me great problems.

[ThatOneGuy]

Hi xoomaster:

I haven't had this problem, but I imagine it is frustrating. And I hope it's not a file corruption. I hate those!

You've studied the problem carefully, and I have no reason to doubt your abilities, but could you confirm whether ...

(1) the Pause script step option is activated, and

(2) the Run script with full access privileges option is not conflicting with any privilege sets you've created?

If the problem is neither of those things above, it might be helpful if you could include the script in your post or attach the file.

Let us know what you find.

[xoomaster]

To answer your question, no "Pause" is used in the find step.

And also the fact that with the same users and the same privilages and same settings, it works 99.9% of the time with no problems but suddenly one time you see an error !

Enter Find mode []

set field ID "Value x"

perform Find

Now you now if suddenly your field ID is changed to "value x" , only if the script had stayed in the Browse mode !

again there are many ways of doing a simple find but somehow the script step :

Enter Find mode []

is not executed and as a result the next step is performed in the browse mode instead, causing an undesirable change in the field "ID".

Hope this makes sense !

Xoomaster

[ThatOneGuy]

Hey xoomaster!

It does make sense, and you're direct answers are helping a great deal! Thank you for taking time to respond.

It sure seems like you've got the structure right and that it should work. That behavior is pretty odd, though. Are there any preceding steps/routines in your script that may be influencing the Find Mode step?... For instance, do you have any "If traps" that might be branching off in unintended directions?... perhaps not, but we may have to dig deeper. Might help if you post the entire script.

Let us know what you find.

[xoomaster]

The actual script body is quiet simple as above with no branching steps, but good point.

Personally I think it may be a problem when a database is shared among many and potentially has to do with the state of an individual record ( locked or unlocked if someone else is using it) ?

I probably have to wait for its next occurance !

I wanna thank you though for helping me through this .

Xoomaster

[IdealData]

I have exactly the same problem where a find mode request does not get started and consequently my data gets over written.

I even put in test to test the current mode but it does not work. Once again, very infrequently!

[xoomaster]

This is a more serious issue than first I noticed. Data integrity is affected by this problem.

Any thoughts? Any steps than can be followed for data safty ?

[Genx]

... Just write an Enter Find mode Script..

Set Variable[$n ; 3]

Loop

Enter Find Mode[]

Exit Loop If[Get(Window Mode) = 1 or $n = 0]

Set Variable[$n; $n - 1]

End Loop

... And call it instead of Enter Find Mode anywhere you have to ... It at least increases your chances of being in find mode...

[xoomaster]

Thank you so much for your response,

Here is the delima

I have probably more than 1000 actual scripts with probably 100's of "Enter Find Mode" script step in them. It is a huge task, but even still by doing that there is no granties !

I am interested in what the problem might be ?

Is it FMP or networking or is it actually a Flaw?

Data corruption in a sensitive DB is a big deal. For example I have noted that after about 120 hours of almost continous use suddenly a field is inappropriately replaced. I have traced the changes in an audit trail to nothing but a find script that seemingly is quite simple !

I think FM staff have to correct this problem fundementally otherwise a escaped step could potentially be another step and not just "Enter Find mode" which in turn is difficult to trace and could cause an unintentional and unpredictable results.

Does it make sense ?

Xoomaster

[xoomaster]

Oh and by the way, for all of us and you guys using FMP in your medical practices, this could interfer with data integrity

"Integrity" §164.312©(1)

Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

So we need action to protect and help the users of FMP in the medical settings.

Xoomaster

[Tim W]

Hi,

Does this trace back to a single script and the enter find mode step within that script? or enter find mode step in more than one single script?

[xoomaster]

There is one Find script that is used very frequently and that is the one I often see errors with it .

see associated list :

The value of the "QD charting 2004 Firstname" suddenly changes to "" ( empty ) !!

The fields labled as _C are actually global fields .

Do you see any reason ?

Xoomaster

Edited December 14, 2006 by Guest

[Tim W]

I don't see anything wrong with the script, except for the fact that it breaks sometimes in your solution. More about the environment, could the issue be user specific, PC or Mac specific, or a privilege set? Does it seem to matter whether the "Run with full access" is selected?

My guess is that it is somehow multi-user related. If you take the database off line and go in on single user (unshared), do you still have the same issue?

Just some straws to grasp.

HTH

Tim

P.S. I am sure you have installed all updates, but if not it's a good idea. A problem with performing finds was reported to FM after install of server 8v2, it was subsequenty corrected in a later updater.

[xoomaster]

Thank you for your input.

It may be related to the environment, but all users and their access privilages have been kept the same for 5 years and no other changes I have made except for more usage !

I have kept up with updates also.

I have made some changes in the script, including checking to see if I am in the find mode before proceeding. Also I have dis-allowed changes to specific fields by all active users except for the Administrator account. So I have to wait and see if this happen again. I have also set it up to report if a field is changed by presenting a dialog box.

Thank you again.

Xoomaster

Edited December 19, 2006 by Guest

[xoomaster]

I have been dealing for a few years now with occasion script step not performing, as if the interpreter in the scriptmaker, jumps over a step !!

This was happening with one frequently used script, and recently I have noticed this with another script step !

This is is at best unbeleviable !

Any one having similar problem ??

I have checked and rechecked my scripts and I have captured proof of this happening, but why, I can't figuer it out ? Could this be a FMP problem or network problem or corrupted DB or what the heck is this ?

Any help is appriciated .

Here is my previous report of this

http://fmforums.com/forum/showpost.php?post/227776/

[AudioFreak]

What script step?

Certain steps will fail on records on a network with multiple users IF the record is being modified by another user.

Set Field for example.

Michael

Edited July 20, 2007 by Guest

[Vaughan]

I've also heard reports of this happening, and experienced it myself with scripts that 1) don't consistently commit records; and 2) don't perform error checking.*

The worst I've seen is where scripts indiscriminately begin with Set Error Capture [ On ] but never perform error trapping or even mildly atempt to programatically deal with steps failing. (One professional developer I worked with instructed me to do this so that users never get bothered with error messages. Yikes.)

A typical scenario is where a New Record step is followed with Set Field, without checking whether a new record has actually been created. If not, an existing record is being over-written.

Script variables, script parameters and script results in FMP 8.5 and later make error checking exceptionally easy and very neat. In earlier versions the error codes needed to be stored in global fields and transferred between files using global relationships, which was messier but not less do-able.

* The only exception is when a script calls an OS-level process like a VB script or AppleScript. FileMaker appears only to wait for confirmation that the process has been *started* before continuing with the FM script, and not waiting for confirmation that the OS-level process has *completed*. This can cause problems if the FM script relies on the results of the process to continue.

[Genx]

A typical scenario is where a New Record step is followed with Set Field, without checking whether a new record has actually been created. If not, an existing record is being over-written.

Out of curiosity, if all appropriate privileges were assigned, when would a set field step run if a new record step failed? I've simply never seen this happen before nor ever read of anyone recommending the practice - Do you also have to run error capturing after each set field step?

Edited July 20, 2007 by Guest

[xoomaster]

Thank you guys for responding. I have already r/o previlage issues and also record being available and not in use.

One example is using a Find script, when somehow FM escapes the "Goto Fine Mode" and instead of finding, you end up replacing a field with your find criteria. This happens 1/10000 probably, but it has a hurrible effect on your data !

I know there is solutions but my concern is why is this happening ?

One can not use redundancy in every script !

I am looking to see If others have similar problem ?

[Vaughan]

Genx

The New Record step can fail for a number of reason, including if the current privilege set does not allow creation but allows editing, or if the file has become read-only (like when copied from a read-only volume under WindOS) but really the issue isn't catching the failure of the New Record step, it's preventing the accidental (and invisible) modification of existing records.

It's not hard or onerous, just 5 extra lines that are easy to copy and paste:

Set Error Capture [ On ]

New Record/Request

Set Variable [ $error ; Get( LastError ) ]

Set Error Capture [ Off ]

If [ $error = 0 ]

Set Field [ ]

Commit Record []

End If

[Vaughan]

FileMaker *never* accidentally changes mode. If that's happening to you then it's a scripting problem, not a bug in the application.

When I've seen weird stuff like this happen it's often caused by Halt steps in scripts, or Halt applied to buttons, so processes can be terminated in an intermediate state.

[Genx]

Well that's my real question though (note i did mention relevant privileges were assigned) -- If the file does become read only, the set field will fail in any case... (as far as i know)....

Not that I've ever had a file go read only on me before when hosted by server, but that's beside the point - Assuming it could happen...

[David Jondreau]

If Allow User Abort [Off] is not set, a user could shortcut key into Browse mode.

The user would have to be awfully quick with the fingers though.

Edited July 23, 2007 by Guest

[David Jondreau]

What kind of proof have you captured?

If you really believe that it's somehow something related to Filemaker itself and not your scripting, you could run a Looping script that enters Find mode a few thousand times and check to see if it ever fails.

[xoomaster]

here is a easy way to demonistrate this :

Enter Find Mode

set field [x] to "SomeValue"

perform find

What we had found that the field X it self kept changing periodically to "SomeValue" which in my DB could only be set in this step ! and only if the "Enter Find Mode" was not exacutated. I have to say that DB is shared between 4 staff, all with the same prvilages.

My actual example is quite lengthy to display.

[Genx]

... That's just weird ...

Allow User Abort[Off]

Set Error Capture[On]

Enter Find Mode

If[ Get(WindowMode) <> 1 ] (i think 1 is find mode...)

Show Custom Dialog[Please Report Me; Error - Couldn't enter Find Mode!]

Halt Script

End If

Set Field[x ; "Some Value" ]

Perform Find[]

If[Get(LastError)=401]

Show Custom Dialog[No Records Found]

End If

[David Jondreau]

It's hard to be sympathetic or even hty to help here. You're being pretty vague. If a failure in this script is the only way a field can get the value of Set Field, why are you searching for it? How does that field get that value to begin with? How do you know that field shouldn't contain that value, you've just searched for a record containing that value? You should probably post your actual example if you want further help.

[Vaughan]

"...If the file does become read only, the set field will fail in any case... "

Ummm, yeah. A really bad example on my part. ;(

"Not that I've ever had a file go read only on me before when hosted by server..."

Ahh, this happens often when a file is uploaded but the permissions aren't changed. It'll be hosted but read-only. Global fields are read/write though.

[Genx]

Okey, Just making sure :

[Vaughan]

Somebody mentioned to me yesterday that the keyboard shortcut for Find (F) is right next to Duplicate Record (D) so it's most probably a typing error that's causing it.

I'm considering the removal of Duplicate Record from all of my Cutom Menus. :

Mind you, I always build separate Find layouts that have a different colour background (light grey for browse, light yellow for find mode) so it's easy for users to know when they are in Find mode or not. These are plugged into Custom Menus so it all looks seamless and works beautifully.

[xoomaster]

Like I said this is a simplified example, to show that if you have not entered Find mode, the field value is changed by this script. So keep your shirt on !

One can use several techniques to help with this situiation if you build in safguard for every possible script you write. Yes you can check if you are in the find mode or not also.

My question is if anyone is experiencing "escaped steps" in scriptmaker here ? I had listed a link to a copy of my original script at the top if you are interested.

The reason for re-posting is that after 4-5 month of use, I have noted 2 incidence of similar problem !

[Genx]

You should probably paste your entire script - There's nothing wrong theoretically with the script, but you say its a simplified version - probably something in the non-simplified part then i'd guess.

[Vaughan]

I don't believe there is a bug in FileMaker, I believe the effects you are experiencing are caused by faults in script programming or user error.

I've just created a little test file (attached), and after 200,000 loops it's not had an error. If the file can be improved please let me know, I'm interested in identifying any problems.

Update: my test is up to 1,500,000 without error.

Find_Test.fp7.zip

Edited July 24, 2007 by Guest
updated the test count to 1,500,000

[David Jondreau]

Could you explain what evidence you have that this script step is failing?

In the example from your earlier post, it appears users enter find criteria into globals, and they may leave the first name global blank. The script enters find mode and sets the respective fields to the globals, then performs a find. You see that the first name in some records is blank and assume that it is this script that is causing the problem.

How do you know users aren't leaving the name field blank on creation or editing it later?