I believe I’ve discovered a bug. When deploying Otto changes the serial numbers in the file being deployed so that the next serial number is set to what it should be in the live file. The issue with this is that in a lot of cases our systems have got the serial numbers defined as “INV0000001” but when Otto updates the next serial value it is updated to be “2” rather than “INV0000002”.
Obviously these days you would use UUIDs instead but, for some of our older systems this limitation can be a bit tricky to work around.
Is this during a data migration? OttoFMS does not do the data migration itself and it does no manipulation of the contents of the file during migration, all of that is handled by the FileMaker Data Migration Tool. If there is a bug with how the data is migrated between files we won’t be able to do anything about it. Have you reached out to Claris about this?
It is possible that your field might be of a number type instead of a text type and the DMT is parsing out the number instead of mapping the whole text entry, which may be something for you to check.
I made a ticket with Claris and they asked me to attempt to use the DataMigrationTool on a fresh file which had a text field set up with a starting serial value as “INV00000001” (incrementing by 1 for each newly created record).
I tested this by migrating the data into a clone. It migrated the data without issue and did not have any impact on the serial number field settings. The prefix was maintained after migration.
Do you know if there is anything within Otto that would cause the serial number prefix to get lost along the way? Obviously I have no idea how it works under the hood but could it be converting the serial numbers in the background to numbers therefore losing the text prefix that I give to the field? I ask this because the leading zeroes also go missing which in my simple mind would indicate that it has been converted from a String to an Int at some point. Forgive me for speculating!
OttoFMS doesn’t have the ability to directly touch or modify the schema or data of your file, every modification of the file is being done using the FileMaker CLIs. The basic process during a migration is as follows:
OttoFMS creates a clone of your source file using a FileMaker backup. This is done using the fmsadmin command line or a backup schedule depending on if the file is open or not.
The clone is moved to your destination server as a build.
OttoFMS uses the DataMigrationTool to combine the data from your destination file with the schema from the clone to make a new file with the data and the updated schema.
OttoFMS puts this file in the right location on the server and opens it with the fmsadmin CLI.
If there is something going wrong with the migration of data, there is nothing OttoFMS can do to fix it. It is possible there is an issue with your existing file that causes it to fail, does the issue happen if you use the DMT to run the migration manually?
Thanks a lot for getting back to me and explaining, I really appreciate it.
I think this may just be something I have to bear in mind as running the DMT on a brand new file doesn’t produce this issue. I have obviously wrongly assumed that Otto was doing something under the hood that was causing this.
It now sounds more likely that its an issue with the file itself and something that we will just have to be careful about when we are using this
