The index that we’re referring to (tablename_ndx) is an autoincrementing primary key that uses the database to keep track of the numbers. In the case of keeping your own machine numbers you would want to add your own column to the table that FSQL creates. It will create the row for you if you specify WHERE “{your_row}={your_value}” in the groups custom WHERE clause. I’ll give you an example.
A common application with multiple templated machines is to have an FSQL group for each machine. Add a “machine_number” column to the table. Each FactorySQL group would have a custom “WHERE clause”, for example WHERE “machine_number = 26” for machine/group 26. The catch is that the item names (columns in the table) should match up. It’s OK if certain machines have extra values - just make sure to show it properly on the HMI side. The really nice benefit of this approach is that a machine is represented by a row. You can easily set up a FactoryPMI screen that is one window that could be used for all 26 machines. The entire screen’s data is based on a query that reads all the selected machines info with a “WHERE machine_number = {my_selected_machine}”, where {my_selected_machine} is a FactoryPMI dynamic property that the user sets via: buttons, a drop down list, etc.
This approach allows you to only create one screen for all similar machines. Adding a machine is simply a matter of adding a new FactorySQL group. You can even populate the users list of choices in a dropdown based on the rows that are in that table. You can see a similar example in this FactoryPMI quick start video.