Scripts online

[VICH]

i have a script that works perfectly in the program, and it is made completely of web compatible scripts but it doesn't work online...why not?

[Søren Dyhr]

Do you mean other matters not grayed out, also makes a wonky performance??? You're probably aware of only 70 of the availiable scriptsteps works in IWP. But setting fields to values does also need to be committed in the script.

--sd

[VICH]

i am using only web compatible script steps though...so it should work flawlessly

[Søren Dyhr]

What about the sprinkling of Commit steps after each Set Field??

It might be better if you instead of letting us guess what the issue could be, you would let us know what you're trying to accomplish with the script ...it might be so that it's not even an issue that IWP can't handle, but instead an ommision of a crutial detail that also would have made the script go rotten in native mode.

But then it could be a step that interact with other programs or the operatingsystem - Copy is one of them, that allthough it works at first sight (not grayed out) would be a dangerous one to use if other users might do similar but not copies and pastes back imidiately ...it not like global fields where each user has their own place to hide data away in. The clipboard is shared with all users.

--sd

[TSilvan]

[quote name=S

[LaRetta]

WOW.

[Søren Dyhr]

WOW.

Yeah Ted! LaRetta have opened a new tread on this particular topic, can't you share your wisdom with us there???

http://www.fmforums.com/forum/showtopic.php?tid/168379/post/169893/hl//#169893

Is what you advocate for that a script in IWP should start with a Open Record/Request step, and end with one single Commit ...quite interesting thought indeed!

The question is then will it solve the observed scripting problem in this thread???

--sd

[Søren Dyhr]

Well Ted You might be right about it, this might to a certain extend be the problem I encounter in this thread:

http://fmforums.com/forum/showtopic.php?tid/168313/

Related to the with 7.0 changed record-locking issues, that dictates that only changes made to portal-rows will lock both parent and child record in question ...is this the reason the firing of the blanks???

Well I just made a test and Yes it seems to do the trick, if you are going to make the portal-rows via parameters in the portals table, is it apparently important to [color:red]open the parent record to prevent the java from jumping to conclusions???

Thanks for the hint!!!

--sd

[Vaughan]

I don't have FMP 7 to test this...

It seems to be that the Commit step is being used to finialise data changes. (I have no problem with thtis.) But what happens if the Open record step is called again? Does it have the same effect or does it do noting, or even does it create an error?

Just thinking aloud...

[CyborgSam]

Remember that web browsers do NOT interact with FM until a script is run, button clicked, etc. The data in fields are actually web forms, not interactive like in real FileMaker.

The proper way to edit fields on the web is to execute a script step to Open the record, then check for an error (to see if the record's busy). If it's not busy, let the user edit it. As noted, once it's opened it's locked. When the user is done, execute the Commit Record script step.

Set fields for globals do not require the Open Record since the global is unique to the user. Set fields for non-globals should always have an Open Record.

One way to do this whole operation is to limit the user's account to read-only access on a layout. When they click an Edit or New button, Re-login the user with an account that has write privs for the layout. At that time, create a record (which opens & locks it) or Open a record.

When I create a user's account, I create the normal account as read-only and create a second account with the suffix _Edit and a password only I know. There is some slight security risk in that the password is stored in scripts and I have no idea if FileMaker encrypts it enough... By using the normal account name with a suffix it's easy to track the user for audit logs, etc.

I gave a presentation at a local UG about IWP & all the gotchas and techniques, but never finished polishing my demo file. One of these days...

[Søren Dyhr]

Remember that web browsers do NOT interact with FM until a script is run, button clicked, etc. The data in fields are actually web forms, not interactive like in real FileMaker.

I know that, but what worries me is what goes on during the scripting why is it nessersary to open the parent record in IWP before going to the related table for batch creation of records ...when the same in native doesn't bother if you make some records that eventually are going to be related due to the scripted fillings of the foreign key.

--sd