Thank you for your post.
I am unable to replicate the issue. This is what I have done:
1. I created a new database file with two tables "Main" and "Related Table". "Main" contains the following fields:
ID (Number - Auto-enter serial number)
2. "Related Table" contains the following fields:
3. The two tables are related by ID = ID. "Related Table" is also set to Allow creation of records in this table via this relationship.
4. In the "Main" layout, I added a portal into "Related Table" with the option "Sort portal records" by Related Table::Name (ascending), and the portal contains the fields Name and Relationship.
5. In Browse mode, I entered one record. ID is auto populated with "1". In Name, I entered "TSGal". In the portal, I entered the following:
(Name - Relationship)
Monica - sister
Eric - brother
Alex - nephew
6. Once I committed the record, the portal was sorted (Alex, Eric, Monica).
7. I closed the file and moved it over to an iPad.
8. On the iPad, I launched FileMaker Go 13.0v8, opened the database file, added a new record (ID = 2), entered the Name "Scott".
9. In the portal, I entered into name "Charles", tapped "Next", and entered "friend".
10. I tapped "Next", which put me in the second portal row, entered into name "Barry", tapped "next", and entered "second friend". Since the record is not yet committed, I remain in the second row.
11. I tapped "Next", which put me in the third portal row, entered into name "Adam", tapped "next", and entered "third friend". Again, all three rows show the same as was entered.
12. Once I tap outside the portal and commit the record, the portal now sorts to Adam, Barry, Charles.
The only time I can get the portal to auto-sort is if I have a script trigger that commits the record.
Let me know what I'm doing differently than you so I can replicate the issue.
I did have some script triggers to run intermediate summary process that required committing the records.
I would like to be able to use these, I thought for testing I removed all the explicit commits but there may
be other dependencies that are causing a commit during data entry.
If you commit during data entry perhaps you will see how the sort leave you doing data entry
on the wrong record if the current record is sorted to the top for instance.
It works as it should. FM will sort when the record is committed and that is how it should work. If you want to go to a different portal row then you have to use the go to portal row script step. Your scripts are incomplete and that is why you are having a issue. Before you commit the record set a variable to get(ActivePortalRowNumber), then commit the record and the portal will sort, then use go to portal row using the variable you set prior to the commit.
Thank you Stacy and TSGal,
As Stacy noted
i am saving get(ActivePortalRowNumber) to a local variable
however if for instance $ActivePortalRowNumber is 3
and I gotoObject Portal and gotoPortalRow 3 after the record is sorted
the active row is now row 1 so going to Row three is no help.
So what to do. Added an serialized index to my portal table.
I want particular records to be floated to the very top when they are entered so,
I sort the portal on my primary record, sort defending on the serialized index
then my special records sort not only to the top but with the most recently entered
at the very top.
This makes it easy to return to the original layout, goto portal object, first row and field before the one I actually want since iOS will advance the field by one anyway. This gets me to the right field with the only two draw backs to resolve being, a flash as the screen redraws which is a bit odd since I freeze the screen and return to the same, or almost the same positions after the commit, and the final resting field is a drop down menu, but only the keyboard appears not the drop down...
You might want to investigate some of the more interesting concepts behind the recently created "selector connector" method of organizing tables and relationships. This is a method that takes "anchor bouy" to a new level of functionality. It has been presented by Todd Geist (Geist Interactive) and by someone from SeedCode. You can find details on their web sites.
One of the features to this method is the ability to create or modify a record in a related table without a layout change. This method thus allows using a relationship to directly modify a record via a specified ID without need to interact with the portal at all and thus the fact that a portal sort moves the record to a different row in the portal does not keep you from accessing data in fields from that record.
I didn't think about the portal number changing, after the sort . You may have to change your design idea and go with something like PhilModJunk has recommended.