Random function starts repeating itself?

[Joris Aarts]

Hi,

Does someone know how the FileMaker Random function works internally and if there has been a change in its behavior between FM versions 7v1-8v3?

I'm having the following problem: last year we deployed 200 FMP7 runtime solutions in which random unique IDs (random combination of 10 characters/numbers) are generated for transactions. The transactions are gathered back and imported in one central database. We never had problems with these IDs until we deployed a new version of our solution created with FMP8v2 last month. Since then we received already 5 newly generated IDs from 3 different runtimes that have a match. Consider A, B and C, then B and C now produce IDs that were produced also in A.

It sounds like a bizarre question, but would it be possible that FMP8's random algorythm has changed in a way that different copies of a file under certain conditions start creating the same random character chains? Like if a certain 'random seed' would have been reset and now the random function starts generating the same sequence of values?

Personally, I don't believe in it. The last days I have performed tests with millions of records on different machines. I merged them into one DB, indexed the field (took one day) and performed a duplicate search (took 30 secs). No results.

But I just want to get peace of mind...

Thanks a lot for your input.

Joris

FMP 7/8 certified

Edited June 16, 2006 by Guest

[Søren Dyhr]

Perhaps read this might shed some light over it:

The random number generator in FileMaker doesn’t work. The numbers it generates are not truly random and will be produced in an observable pattern. (It is important to stress that random does not mean unique! It is OK for a random number generator to produce the same number multiple times. It is not OK for it to produce numbers in a pattern, which by definition is not random.) Before you write a nasty letter to FMI, you should know that the same is true of every random number generator in every software development package. None of them produce numbers that are truly random.

Snipped from the "Random Violence" chapter from:

http://www.foundationdbs.com/Downloads/WhitePaperForFMPNovices.pdf

A read here could do the same...

http://en.wikipedia.org/wiki/Pseudo-random_number_generator

--sd

[Oldfogey]

Back to the original question. I do not remember any reference to a change in the random algorithm but that doesn't mean there hasn't been one. In fact, there have been so many goodies added, it would not be surprising if FMI has improved the algorithm. I seem to recall some rather hefty criticism of the FMP random algorithm but that could be my memory.

More to the point, you seem to have confused 'random' and 'unique'. If a random value generator did NOT generate some duplicates it would be a faulty generator.

If you really want unique values, you need to add a location key for each db copy distributed and combine that with the randomly generated value.

[comment]

If you really want unique values, you need to add a location key for each db copy distributed and combine that with the randomly generated value.

As you have pointed out, a local generator can generate a duplicate all on its own.

If you REALLY want unique values, use a serial number with a local prefix.

[Joris Aarts]

Thanks a lot for your valuable feedback. So you all seem rather suspicious concerning the use of randomly generated unique ID's? I don't remember when and where I picked up this technique, but I have been using it for years in various projects without any problem. I must have been lucky so far.

More to the point, you seem to have confused 'random' and 'unique'. If a random value generator did NOT generate some duplicates it would be a faulty generator.

What I'm doing is concatenating 10x a random pick from the alphabet via a custom function, like:

Middle("ABCEDFGHIJKLMNOPQRSTUVWXYZ0123456789"; Ceiling(Random*36);1). This would give me a chance of 1 on 36^10 (3.656.158.440.062.976) to get a duplicate. If only FileMaker would generate better quality random values, as you suggest ...

Strange, though, that my tests with millions of records didn't reveal the presumed FileMaker random pattern.

[Razumovsky]

You should start playing the lotto.

So you all seem rather suspicious concerning the use of randomly generated unique ID's?

As was already pointed out, a completely "randomly generated unique ID" is an oxymoron of sorts. If it happened by 'chance' once, it could happen by chance again. Non-random parts NEED to be included in the ID in order to prevent this (as in the prefix + serial suggestion).

I have seen random elements used in keys before, but always as a failsafe (if for some reason records were imported back screwing up serial or getID functions, and users committed different records at exactly the same time and one forgot to log off from the other computer while being distracted by the swine who had just flown in to alter the date settings on the OS, then the random part of the key would prevent it from being duplicate (unless they were really really lucky...))

-Raz

Edited June 18, 2006 by Guest
forgot the serial after prefix...

[Søren Dyhr]

I don't remember when and where I picked up this technique, but I have been using it for years in various projects without any problem.

I think it was in an article by Ilyse Kazar and Anne Verinder in the approximately year 2000...

Approaches were different back then with pre and postfixed concatanated keys, where multicriteria keys have made the digestion and indexing of a massive key a less important issue.

Their perhaps not deliberately expressed request, was to make an as compact key as posible, while simultaniously exhibiting some kind of uniqueness and distinctiveness.

I have no idea how broadly the change of paradigma from fm6 to fm7+ have made people change from textkeys to numerical. But if you make CF's are they less damanding to construct the recursions from.

--sd

[Vaughan]

You posted earlier that the problem occurred with FMP 8.0v2. This version introduced problems with unstored claculations that prevented them from being re-calculated -- which means the Random function might not have been working.

The problem has been fixed with FMP 8.0v3 and this is a highly recommended upgrade.

[Ender]

You posted earlier that the problem occurred with FMP 8.0v2. This version introduced problems with unstored claculations that prevented them from being re-calculated

I don't remember such a problem. Did it affect auto-enter calcs too (I image this serial number is made with in an auto-entered calc and not an unstored calc)?

[Vaughan]

Ender, it's the issue with calculations being evaluated on either the client machine or the server.

It might *not* be the issue, but it's sure worth usgrading to FMP 8.0v3 to test it out.