6 Replies Latest reply on Aug 15, 2012 11:09 AM by philmodjunk

    Auto-serialization Issues



      Auto-serialization Issues


      I am trying to make a hardness test report. The report basically consists of two databases, one being used as a portal reference and one as the main databae interface. The report is set up so that each part gets tested three times. Those values are typed into specific portal fields, then the values are averaged and the average shows up in a fourth portal field. I have a fifth portal field that acts like serializing counter. The field puts a 1,2,3...in front of the hardness test values to indicate 1st part tested 2nd part tested etc.... It does this automatically.However, it has some issues with the functionality. If I have to go back and fix a typo in a hardness value field that I had typed in earlier, then the serialization restarts itself from that line and stops iterating for any new lines.

      I also don't always want the serialization to start at 1, so I have made a field where you type in the value you want to start with and the serialization will begin with that number instead of 1. This seems to work unless I have to go back and re-type in a hardness value. It restarts the serialization from 1. Trying to make this work is a bit above my skill level with FMP and I'm not going to be able to do a great job of explaining how I even got the serialization to slightly work. So here is a link with the file. Looking at it will probably make it easier to see what I've done. The layout to go to is called hardness testing.


      If anyone can help me get the auto-serialization to work correctly, I would really appreciate it.


        • 1. Re: Auto-serialization Issues

          The report basically consists of two databases,

          I will interpret that as a report with two Tables. A database can consist of many tables from many different files in FileMaker. Wink

          Any chance that you can upload this to a different share site? Unless they recently changed their policies back to what they had originally, you can't download from that site without first signing up with them. It was the final straw that led me to drop them as a share site and switch to using drop box--which both has no such requirement and also does not bombard you with obnoxious ad links while you making you wait for a down load link. A few of the ads that have popped up on this site are not the sort I'd care for my boss or family member to see on my screen. Others have tripped my virus protection software.

          I would guess that you have an auto-enter calculation and or a summary field that is producing the serial number. If it's an auto-entered calculation, you can post that calculation here without having to share the entire database file.

          Also, letting us know what layout, tables and fields are used helps us to quickly go to the right place in your file to see what's been set up. If you have a lot of different layouts, we might have to waste a lot of time searching out the details.

          • 2. Re: Auto-serialization Issues

            I got side tracked last week and completely forot to set up a link for you. Here is the link to the file in my drop box account. https://www.dropbox.com/s/lvvqz91dryymp5k/Mechanical%20Testing%20Results.fp7

            • 3. Re: Auto-serialization Issues

              If you use a timestamp for each record then you can sort by that created or finished timestamp.

              Your problem is that some modifcation to the record restarts your serialization. If you instead base it on a non-changing timestamp entered when the record was created or when you deliberately click a finished button, then the problem will disappear (in theorey, of course).

              The only reliable method of serializing is to deliberately force the serialization as records can be added, deleted, modified, etc. which makes it hard to serialize sequentially.

              So, GTTR to a table view. Sort by timestamp or otherwise. Then do a replace field using the serial number optin set to 1. This may fail occassinaly when someone has one of the records open for modification.

              • 4. Re: Auto-serialization Issues

                Ok, downloaded the file and am tracing the references...

                Question: Do you use this database as a single user database or might multiple users be entering test data at the same time into the same hosted file?

                I have made a field where you type in the value you want to start with and the serialization will begin with that number instead of 1. This seems to work...

                Actually, it doesn't work. I entered an override value of 50, clicked the layout background to commit the record and then entered data into a new portal row. The result was 56--the number of records already in the portal less one. This is exactly consistent with the calculations you have defined, but not what you want as far as I can tell at this point.

                I can't reproduce this behavior:

                unless I have to go back and re-type in a hardness value. It restarts the serialization from 1.

                I've tried editing a hardness value to change the value and then created a new record by entering data in the add row of the portal. Doing so does not stop it from numbering the next sample as: The number of portal records + the override value - 1.

                As a single user file, to get the next record in the portal to show the Override value + the number of records added since the override value was last changed, will require a different approach. Before I play with ways to make that happen please answer my question about whether this is a single user file or not and then answer this question:

                Under what circumtances would you want to manually change the next number in the sequence? (Why do you need to do it?)

                • 5. Re: Auto-serialization Issues

                  I may have incorrectly described the phenomenon occurring when the serial numbers reset themselves to the incorrect number.


                  To make the serialization compute incorrectly, you can follow these 5 simple steps!


                  1) type number into first hardness input field

                  2) go down on line and tyoe a value in the fliew below it, the serialization should be 1 & 2

                  3) repeat this step 2 or three more times

                  4) go back to the value typed in for serial number 2 and modify it

                  5) exit that field, the serial number will reset to what should be the latest value


                  I attached an example

                  • 6. Re: Auto-serialization Issues

                    Does step 5 happen and you don't want it to happen or is step 5 the change you want to see happen and it doesn't?

                    I'm not seeing any change in serial numbers when I modify a test value so I'm guessing you want the record to renumber itself if a user modifies the data, but that seems a very strange thing to do here...