Commit, commit, commit, commit, ...

[Frankywinky]

Okay, recently we converted our bases from FileMaker 5.5 to 7, because there are greats improvement. However, it gives me hours and hours of readjustement, some functions does not work exactly the same way as before, and etc.

But now, since our users begins to use the database, there is a huge problem happening at a lot of places in our databases : A message complaining that there is another user reserving a certain record.

The point is, when an user makes changes on a record from a portal, and then use a button that is automatising tasks, the script complains that the record is used. And sometimes, a script is used and the user can't do anything without quitting the record because the script was using the record. (Note : when there is a portal to another base, it means to another file because we have one base a file). The only thing I can do is to put a "commit" in the begin of the script and then "commit" in the end. In all of my script used in portals!!

But, when we were using 5.5, there was no such problems and we get used to work with an "auto-commiting" database. So beforce adding "commits" everywhere in my scripts (and there is a lot to do), do you think there is another way? I means, maybe a plugin or a FileMaker option to auto-commit all user and script changes?

While ago, I was happy to see that FileMaker was implanting Commit. But now, I see only disadvantages, it only makes the users occupying a record more longer.

And there is not a lot of users using any "roolback" anyway.

So is there anyone a way to enter an auto-commit mode or anything like that? Or is there a way to not add "commit" two times in all of my scripts ?

Thanks.

[Wim Decorte]

It seems you converted a bit too quickly without taking into account all the changes. This is where a good MetaDataMagic analysis with the Conversion Issues would have been a great help.

Generally you do need to add Commit steps after a bunch of scripted Set Fields to avoid leaving users in uncommitted records.

[Fenton]

The main place that I ran into this, in a converted file, was when creating a new record in a child file (table), then returning to the parent file (table) and entering the new row of the relevant portal. It was necessary to commit the parent record (which commits the portal record also), before entering the field (in the new portal row). That will probably solve most of your problems.

I also don't use the "rollback" feature. But maybe sometime I will. It is really not that hard to solve these commit glitches. It does not "make users occupying a record longer." Just entering a field no longer locks a record. Read Ilyse Kazar's excellent chapter in the big "migration_foundations.pdf" file on the FileMaker migration white papers site. It clearly tells when a commit is needed, and when a record is locked. 7 is much better than 6.

[Frankywinky]

Thanks for your replies

Wim :

We could take more time doing test before conversion but there was too much things to do. We have a lot of tools using SQL and the old web publishing solution in CDML converted in XSLT. It tooks month making modifications and it was sure that some issues like this were to happen when we released the new version of the database. Now, it is too late to do another convertion. We will repair all problem one by one in the actual version. But, thanks for the tip.

Fenton :

This is true, principaly the problem occurs when creating a record in a portal. But this is not all the problems (because we already solved that). Just by example, when a user is editing a field and then click on a button doing a script. I don't know why, but the focus remains on the field and the error occurs. I did not found any solution to this but telling the users to click elsewhere on the layout before clicking a button. And sometimes, users are telling me they have got a similary problem (the record is in use) there and there for some obscure reasons.

I taked a look on the "Migration Foundation" doc. It was interresting. Like you said about occupying a record, I did not realised how the record was really locked. Maybe I did not realise that most time, the real problem was that when the user remains the focus on a field. But, the doc did not help me solve these problems. I am in the "Test, Test Again, and Test Some More!" state (Migration foundation p. 84) :

So, do you have any idea to avoid this problem? (When a field is modified and the focus remains on the field and then a button is clicked. Because of the focus, the field is considered in use.)