1 of 1 people found this helpful
I suggest that you add an extra table, called 'Serial No' with a script that just adds a new record and returns the next serial number as its result.
Then you can call this script to get the Main Number when you need it, or don't call it when you just want to add a suffix to an existing record. Take the auto-enter serial out of your main table.
I've been using this method for a few years now. The extra table has only a few fields and doesn't slow the system down.
Best wishes - Alan Stirling - London, UK.
+44 (0) 20 7724 2456 - firstname.lastname@example.org - www.ast.fm.
FileMaker Certified Developer for versions 7, 8, 9, 10, 11 and 12.
1 of 1 people found this helpful
You can get and set next serial number in a script. If your script captures the next in a variable before the duplication then sets it after the duplication you can retain the next serial integrity.
Lyndsay & Alan,
Thank you for your responce's, It is always good to get some outside perspective on things.
I ended up doing something interesting, and would like to hear what you think about it if you get a min.
I went ahead and auto assigned the Serial number, added an additional digit so the serial number that I needed was 8345 I put in the Auto field 83450 Then I had it tick up increments of 10.
Then I created a New Record Script / Duplicate Record Script as such:
This way if by chance I am not duplicate the record and just creating a new one the serial number handles it just fine with no outside help. however if the record is duplicate and rev'ed up it I force in the new number and reassign the serial value.
Does this work if you have more than 9 "DUP" records?
I guess I would separate your serial # and your rev/dup #, then concantenate them later.
Auto enter your rev/dup number to be "0" and have a field that is:
aQuote_Number & "." & aRev_Number, calc result is TEXT.
New records will allways be ####.0 and for your DUP script, I would use Lindsay's suggestion to get the next serial value before the duplication and reset it after, then set aRev_Number = aRev_Number +1.
That way, you could have something like 8345.27.
Hope that helps!
Do you have the possibility of more than one user adding records at the same time?
The method that you describe might not work correctly if one user's script is about to reset the serial number, whilst another generates a new record ...
But this only becomes a problem for a multi-user system. For a single user, your method will work fine.
Best wishes - Alan Stirling, London UK.
Yes that looks fine...
There are always many 'ways to skin a cat' (how cruel).
Alan's point is valid regarding multiusers. I was thinking also that his suggestion in an inverse circumstance might also be the go... ie to have standard serialisation of the master records and have revisions as a related table.... also serialised with the dot-points.
Message was edited by: Lyndsay Howarth
You are correct after 9 it would get confused, I knew this going into to it. The most DUP's we would have would be 5 so 9 provides a nice buffer for the just in case.
Yes this is a multi user Database, however this function might happen 10 times within a 30 day window. It is not a very high rate of people clicking and creating therefor the chance that it could happen is there, but I think it is a very minor chance.
Moreover I would also say if they are just creating a new record it uses the regular serial number methods which would further reduce the rate of it happening.
That always make me nervous. Just because you (the developer) can't see a case for more than 5, doesn't mean that your users or business rules might change down the road. I always prefer a solution with no real limit, even when it isn't seen as a need right now. YMMV.