Jump to content

Random function starts repeating itself?


This topic is 5640 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

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 by Guest
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Newbies

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.

Link to comment
Share on other sites

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 by Guest
forgot the serial after prefix...
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 5640 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.