Hi all,

I've done a test upgrade, and alot of scripts we have for automated
processes (IE, the script is running on a client machine in a loop)
seem to be failing.

It looks as though I'm having to add Commit records when copying data
using Set Field from one field to another field in another file.

Is there anyway around this behavior? We have LOTS of scripts, and
finding all the places where i need a commit record will quickly become
time consuming.

Any ideas?

Thanks
Andy

In article <1128110100.520741.240390 (AT) g44g2000cwa (DOT) googlegroups.com>,
ajohnstone (AT) capcitypress (DOT) com says...
Perform a full review.
Be liberal with the commit records - they can't hurt the system. Too
many is better than not enough. Stick them in after blocks of setfield,
and after new-record/requests. That seems to pick up most of the damage.

Watch out for performance problems too. I've seen some nasty ones crop
up with upgraded solutions. Drop Down Value Lists that take a minute to
populate (workaround: convert to popup menus). Auto-entercalcs that take
30 seconds (workaround script new record creations and change the
autoenter calcs to setfields) and so forth.

Don't stress on it & plan for a database rebuild. FM7/8 is such a
radical departure from 5/6 that in my opinion, once you've got your
solution working well enough to be usable, start building its
replacement.

42,

Thanks for the advice. I guess thats true that too many commits can't
hurt.. I'll have to start doing that.

I've already encountered the popup list performance problem (and found
the popup drop down solution), but other than that performance seems
much improved. Of course that may be partially due to the shiney new
servers that will be replacing the old NT 4 machines ;-)

Its a shame we'd have to rebulid after an upgrade. We are starting
large project here which may replace a good portion of Filemaker apps,
but it likely won't be with Filemaker.

I'd better start adding those commits in :-)

Andy

42 wrote:
In case you missed it, a free FM7 upgrade was released last week,
specifically to address this value list problem. FM 7.0v3a is available
in the download section of FileMaker's website.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

In article <11k2kr9ijhut02d (AT) corp (DOT) supernews.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...
I did indeed. Thanks.

-Dave

42 wrote:

How about FM just fixes Set Field instead?

Did I just read correctly that in FM7/8 that you can't trust Set Field?

It's not that you can't trust Set Field, it's just that you need to plan
for its new behavior. Prior to FM7, the Set Field step would lock a
record, change the data, and unlock (exit) the record. In FM7/8, Set
Field will lock the record if it's not already locked, change the data,
and will remain in the locked record. The benefit of this is that you
can now run a series of Set Field steps without the time and resources
it takes to lock and unlock the record for each step. Now you just have
to remember to include a Commit Records step at the end of each script
(or don't include this step if you want to leave the cursor in a field
and let the user make more edits or revert all your changes).




Paul Bruneau wrote:
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

In article <1128369729.749155.234490 (AT) g43g2000cwa (DOT) googlegroups.com>,
paul (AT) ethicalpaul (DOT) com says...
You can trust Set Field to work according to the FM7/8 documentation.

Unlike FM3-6, set field (and new record for that matter) in FM7+ opens
(or locks) the record, but dosn't immediately commit (or release) the
record. You must explicitly commit the changes.

(Note that if you don't commit them via script, they WILL still happen,
they just don't happen *until* you do do something that commits them, up
to and including quitting filemaker.)

The downside of all this is that if you setfield, and then reference a
relationship on that field without commiting it won't work, calculations
won't automatically update, and so forth, which is the 'broken'
behaviour everyone notices. Adding commit records steps in the
appropriate places resolves it.

The UPSIDE of this new behaviour is that its a consequence of the new
record locking model in FM7+ ... the one that doesn't automatically lock
records just because a cursor is in a field, saving us from hundreds of
situations where people walk away from their desk with a locked record.
(They can still do it, if they actually edited the record, but many many
many incidental, unintentional locks have been eliminated.

Of course, we still NEED to be able to lock a record, and keep it locked
while we do a batch of setfields to it; since simply having the cursor
in the field doesn't do it the set field behaviour itself has been
redefined to require an explicit commit.

There is an excellent reference at filemaker.com in the technical
briefs. Here is the direct link.

http://www.filemaker.com/downloads/p...grtn_found.pdf

In article <11k37unjk5ik36e (AT) corp (DOT) supernews.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...
In my opinion, more importantly the simple performance boost is that we
-need- some way to keep records open after a set field in order to do
'transactions'.

Previously we could simply stick a cursor in a field to lock and then do
a batch of setfields; as long as the cursor was in the field the record
was locked and stayed locked even if we commited it.

With FM7+, if we do an action that commited a record (like set field),
the record would be immediately unlocked (the cursor would still be in a
field, but would not hold the lock, making it effectively impossible to
do a batch of setfields as a "transaction".

Good point about the new ability to allow the user to -revert- such 'set
field changes' on uncommited records.

Howard Schlossberg wrote:
Of course the down side is that I now have spent days of effort adding
Commit Record commands to key places in scripts. And its not everytime
I use Set Field either there are places where the Set works fine and
can be read immediately, but other places it doesn't. So instead of
upgrading and going on my way, I have to expend effort 'fixing'
something that was already working.

Which, again, is fine for new development, but most of us are
upgrading. I think an option to use the old behavior would have been
nice..