Random passcode

     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.

     

          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.

     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.

     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 ]

     @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...