Random passcode
I'm looking to generate a random 4 digit passcode for all our current employees and employees to come and I need to make sure they are all unique. I thought that I could use the auto-enter random calculation and select unique value in validation but I'm worried that this could cause a loop or some sort of strange error in the off chance that the same number comes up twice. Any suggestions to avoid this or is it not a concern?
And then to assign a passcode I'm assuming I could launch a script that starts at the first record and then loop from there until it finds the first unassigned match field?
Will the sort order forever remain in the same randomized order or will it change everytime it gets sorted?
And then to assign a passcode I'm assuming I could launch a script that starts at the first record and then loop from there until it finds the first unassigned match field?
You could. Or a relationship that only matches to unused records could be used...
Or you can perform a find for all unused records and then sort them by cOrder...
Will the sort order forever remain in the same randomized order
It depends on how you set this up. If you refer to the records via a relationship, you can "hard wire" in this specified order by specifying a sort order in the relationship.
In other circumstances, you may need to be sure to always sort your records before accessing them. Performing finds, for example produces a set of unsorted records--which in this case will produce a set of records listed in the order that they were created instead of the pseudo-randomized order I have described here.
Which would get me the best performance:
A script that goes to a layout which has a portal linking my personnel Records to my pass code records, with a (can't think of a better word then filter) built into this relationship to remove all used records. Simply go to the first protal row, link it to the employee in question, mark it as used and return to my personnel records.
Or creating a sorted relationship between the passcode and itself once again and in this relationship having the "filter" to remove all used records. Grabbing the first record that pops up, linking it and then marking it used.
Obviously open to better ideas if there are any, these are the only two scenarios I coud come up with. Thanks!
The most optimum Card Deck shuffling is to "Deal off the bottom of deck"
Creating a Table of just sequencing numbers from 0001 to 9999 ... i would never use "0000" for reasons that should be obvious.
I would do a Loop which would make 9999 records, thus record number 1 would be "0001" and record 9999 would be "9999", This would be a "one time" shuffle so to speak.
Now do the random pick as Phil showed. Let say you got random number 1255 or record number 1255 which has a field of "1255".
Now the Bottom of Deck....
Exchange fields data from the last Record [ 9999] and 1255 and save in a global field in this table 9999-1 or 9998 [new bottom of deck pointer]. Assign 1255 to personnel.
Next time generate your random number from 1 to 9998, thus elimiating the "bottom of the deck".
Say you get 4789 this time.... exchange that record field with record # 9998 , decrease you pointer to 9997. Assign 4789 which is now at next to last record.
Next random number is between 1 and 9997. and so forth. if you looked at a list you can see the order each number was assigned at bottom of orginal deck,
You could put a timestamp and personnelID in the "Deck" when it was assigned.
No find , no sort, quick and easy.
Jim...
oooppps if forgot to show how it is "unique"
Say on third try your random number generated 4789 again. The number would be "9998" since we exchanged that number in the step before.
Exchange the record data again... decrement your global to 9996.....
ooppps your genereated number hit 4789 AGAIN.... guess what number you will get,,,,, if you said "9997" you win a bubble gum cigar.
Jim...
Jim,
Take another look at the method that I am describing--which I've used to produce randomized lists for "pinewood derby" style randomized flight, heat and lane assignments.
No such 'dealing from the bottom of the deck' is necessary.
Sorting the records once by the value in the random number field is sufficient to put the values in a random order. There is no need to generate any additional random numbers. After sorting, you simply start at the top and start assigning the values in sequence.
So would you suggest any of the two senarios I mentioned above Phil?
Jim, wouldn't assigning the pointer completely reset itself the next time I shut down FileMaker? These random assignements happen once in a blue moon so I need to it always remember which have been taken and which haven't.
I'd use this method.
Set up the Used field to auto-enter the value: 1 when each record is created.
Define this relationship:
YourMainTable::constUnused = PassCodes::Used
define constUnused as a calculation field that returns number and that has this calcualtion expression:
1
Define a sort order in the relationship that sorts your related recors by the random number field.
Then this script can assign the next passcode to a field in YourMainTable:
Set Field [YourMainTable::Passcode ; PassCodes::PassCode ]
Set Field [PassCodes::Used ; 0 ]
Ah yes, far simpler. Thank you!
@Matty Phil and I and others think that a healty discussion is beneficial to the forum. This is NOT arguing.
Globals...
I use a simple method to Save Globals, especially if you are using your DB on a Server. I create a Table with just 1 record and link that table to any other table needing a global storage. Then any field in the single record Table is a global. I save things like ... version number, last backup date, fiscal year, etc. I use that table as my DB navigational page to move about various aspects of the DB.
In the case of Dealing off the bottom... the global could be calculated from the Found Count of ....
YourMainTable::constUnused = PassCodes::Used
@Phil I am sorry i did miss the Sort which is doing the randomization. Since Random should generate a Uniform set of psuedo random numbers, your method should be OK for non critical use. The Deal off bottom , on second thought, does "Sort' with your swap filed contents but doesn't use FMP sort or Find, therefore is the fastest method. It has been found to be the "Optimum" over the years. The table shows the sequence of issue with the swap.
@Matty After many years of people forgetting their passwords, I intercept their passwords and save it with their User names in their personnel records. So when you get the enevitable.. "I forgot my password" The admin can reset or retrieve it. You can Scramble their password using the XOR function and a key.
good luck
Jim...
Of course it's an argument! BUT it's not a personal argument! 
Thus we can have fun batting ideas back and forth in an intellectual argument and hopefully others such as Matt can gain from the discussion and make their choices from the alternatives being discussed.
@Jim,
That "Optimum" argument is a good point, but the the number of values involved may make it a moot point. The difference between 3 blinks of an eye and 1 blink of an eye may not be detectable by us slow humans. Of course, as the number of values in this table increases, or if you involve slower systems such as a client using Fm GO on an iOS device, that "Optimum" argument may not be at all "moot".
@Phil blinks of an eye and memory used to store programs and their data was valued more a few years ago. One of my favorites was programming a Toggle or Flip-Flop function. LIke this...
Toggle = IF( Toggle = 0 ; 1 ; 0) // each time called flips true to false and false to true.
National winner for speed and memory...
Toggle = ABS(Toggle) -1 // does the same with less memory and nearly 10 times faster.
Oh Well...
Jim...
Jim,
Could you walk me through an example on how to "scramble" passwords? I have a few employees that notoriously have difficulties recalling their passwords and I find them using thing like excel to track their information, obviously a serious security concern. I'd like to offer them the option of keeping all this information under on roof.
If these are FileMaker passwords, they do not need to be unique to the individual user. The Account names, on the other hand can be unique. You may find that you do not need to store any passwords at all--storing them can be a security risk unless you store them in encrypted format. There are ways that you can assign every new user the same "default" password, but require them to change their password the first time that they access the Database. If they forget their password, you reset the password and require that they change the password once again the next time that they access the database.
@Jim, I can't resist. Why not this expression to flip flop true and false values?
Not Toggle
Sorry should have made myself a little more clear, I mean generally keeping track of all sorts of passwords .... apple IDs, google calendar accounts the list goes on and on.
I would love to have the ability to store encrypted passwords for these poeple. sure beats excel and notes on the their macbooks that aren't password protected.
Check for an encryption plug in. I think there's at least one that could be used to store the passwords in an encrypted format.
@Phil Remember this... FMP is an "Interpreter" not a compliler. The NOT function is just a simple "Truth Table" in FMP using boolean results and is [no pun intended] not a true compiled NOT used by the micro processor. Where the ABS function is compliled as a simple "change the sign bit off". All math funtions are compiled [they have to be]. I will buy you a cup of tea in an 100,000 trial benchmark test if i am wrong.
.
@Matty I forgot the FMP function XOR is a truth table and not a compliled exclusive OR in machine code. Meaning you get a 0 or 1 not a number.
Security....
I use FMP security to keep people from "peeking" at other accounts. But a simple, visual scramble can be done using FMP Char(field) and Code(field) functions to keep the peekers confused. It is not intended be Hacker resistent. But you can add a level of security with a keypass word.
The keypass word is still subject to being hacked. Lets say for example your secret key password is "X1313B" called $KPW
All passwords could one time local of $PW and be shown in a Number field calculation called Scrambled and used in FMP to Reset Account Password.
Scambled = Code($PW) * $KPW Using say a user $pw of say..."Matty1234"
This is the result of that calculation...
682766696365650643385887452309523092736201101 [stored] can you figure it out?
to reverse and see the orginal $pw used in Reset Account Password
You must use your secret Keypassword of $KPW, not stored.
Unscrambled = Char(Scrambled / $KPW) [not stored]
After reading your last remark, i agree with Phil, there are addon to help. Apple OS uses a application named "Keychain" to do what you want.
Jim.....
"
@Phil I did the bench mark on FMP12 of your toggle calculation...
Not Toggle
versus My toggle calculation....
ABS(Toggle) -1
And I owe you a cup of tea
On a Loop test to 1 Million loops your "less interprated" line won by 4% faster or ~4 sec diff.
Yours took 83 seconds on my MacBook Pro 2GHz core i7
Jim...
PS: Grasshopper bows to the Master
Actually it was a stupid ( I thought ) comment produced by not fully reading one of your posts. 
I do find that many arguments about whether one expression is more efficient than another is moot. Unless/until you are talking about very large data sets, may such cases are a matter of does it take one blink of the eye or two?
Of course when you are dealing with massive data sets, then those little differences can add up in some cases to significant performance differences...
Define a table with three fields: Passcode, cOrder, Used
Define cOrder as simply:
Random
Use this loop to produce 9999 records in this table:
Loop
Exit Loop if [$K > 9999]
Set Variable [$K ; value: $K + 1]
New Record Request
Set Field [Passcodes::Passcode ; Right ( "000" & $K ; 4 )]
End Loop
Then, if you sort your records by cOrder, you get these values in randomized order to use as your source of passcodes. (This is analogous to shuffling a "deck" of 9999 unique cards and dealing one card to each recipient.)
The example that I have posted is a "proof of concept" example. More sophisticated versions could produce alphanumeric codes.