You could, but it will be far simpler to create a new record with each new instance that you want to log instead of filling in repetitions in a repeating field.
While a script can loop through the repetitions until if finds an empty one into which to log the data, consider what would need to happen after all 10 repetiions have been filled...
after 10 repetitions have been filled just go back and overwrite from the top again.
can I have steps by steps scripts for that please? and where am I gonna use the script in?
thank you so much Phil
And then how will you tell which entry is the most recent of the 10?
Seriously, it will be much simpler to use a related table to log your account name changes than it will to use a repeating field.
If you must, define a number field to go with the repeating field. Set it up to auto-enter a 1 when the record is created. Call the field "NextRep".
Then this script will log data in the next available repetition:
Set Field [ LogTable::RepeatingField [ LogTable::NextRep ] ; Get ( AccountName ) ]
Set Field [ LogTable::NextRep ; Mod ( Log::Table::NextRep ; 10 ) + 1 ]
how about modification date and time?
To repeat, a related table is a better option.
But you'd need additional repeating fields if you insist on that approach and the above script would have one set field step for each--all using "nextRep" to access the correct repetition of the fields.
Yes I think it's getting complicated.
how can I set up if I'm going to use a related table?
I think we've discussed similar situations before. I don't know how you are detecting the account name change. I will assume that you have a script for that. The script for such, can do this:
Go to Layout [UserAccountChangeLog]
Go To Layout [original layout]
//Put the steps to change the account name here
The fields in UserAccountChangeLog can auto-enter the creation account name to log the old account name along with date and time or a timestamp field that likewise logs the date and time that the new record was created.
You'll also need some value other than the account name that ties all account names for a given user together. That would require some kind of user table with an ID--such as an auto-entered serial number for each user. You'd need to enter that ID number into a field in this table as well. There are many different ways the above script can do that, or it can be an auto-enter calculation if you have already loaded such a value into a global field or global variable before the New Record step is performed.