Please spell out what you are doing in more detail? A record cannot be committed until it is first opened for editing such as by clicking into a field in order to modify the data in it. Then there is more than one way to commit the record, which way produced this result?
And if you create a brand new simple test file, do you get the same behavior? IF not, the issue could lie with the specific file that you are using.
The key facts are:
-it works on Mac/FM11
-it works on Mac/FM12
-it works on Win/FM11
-it works on Win/FM12 when the layout is in list view
-It does NOT work correctly on Win/FM12 when in FORM view
I think Phil was hoping more info about the problem itself when he asked to spell out... Check one :
a ) the commited record become the first of your found set (sorting problem)
b ) the committed record is leaved and then you are browsing another that is the first of your found set (navigation problem)Other questions :
• Is the bug occuring even the record is not modified ?• In all cases, is there a script trigger defined on the layout properties or in a layout object ?Bye, Fred
I've got any number of FMP 12 files here that I use on my w7 systems and the current record does not change when I edit a record in Form view and commit the record. Thus, a closer look at the design of your layout/database would help narrow down what part of your design is responsible for this change in current record.
And this doesn't mean that you haven't uncovered a bug, just that there's more involved than just committing the record--maybe there's a specific script trigger or script step that is behaving differently in FMP 12 than in earlier versions.