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

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.

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.

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

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.

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

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!

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 ?

... 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...

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

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

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?

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, 200619 yr by Guest

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.

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, 200619 yr by Guest

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/

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, 200718 yr by Guest

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.

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, 200718 yr by Guest

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 ?

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

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.

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...

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, 200718 yr by Guest

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.

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.

... 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

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.

"...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.

Okey, Just making sure :

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.

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 !

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.

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, 200718 yr by Guest
updated the test count to 1,500,000

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?

I'm beginning to think this is cold fusion.

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 ?

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?

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?

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)

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

Well played sir.

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

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 ?

... 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.

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, 200718 yr by Guest

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?

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

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.

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.

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.