Filip,
we've come to a point of an inactive thread. The question then always is, whether you gave up on this or found your way.
Anyway, as we now know you wanted to create a random unique alphanumeric ID there was a related discussion about whether SYS(2015) is usable as an id in thread184-1830311.
To use an alphanumeric value as a unique id has pitfalls. Randomness can be enough, if the value generated is long enough to avoid collisions (duplicate values) by chance. One point is that this never can be guaranteed by randomness alone, as improbable as it becomes with large ranges of values. But you can define the population of a field with a unique value using such an almost never failing generator by reusing it, if the number it generated turns out to be a duplicate of something already generated beforehand. That means, it's enough to have the primary key checking uniqueness and in case of an error just generate one more random ID value.
This would work fairly well and only lead to rare double calls of the random id generator and even less so triple or more calls necessary. The major ingredient is the range of values being very large, 36 different characters 0-9 and a-z, or 62, if you include A-Z, would give exponents of 62 as the number of different values and that easily becoms larger than astronimical numbers already with 10-20 characters. So the chance of double values is essentially zero. But if you think of the extreme case of flipping a coin only giving 2 results, you can have 2 records, one for head and one for tail and you can flip coins as much as you like if the generated values only are either head or tail, there won't ever be a third random value usable as id of a third record, so the vastness of the possible IDs is important.
If you generate a unique value for a database the only two very well defined ways are a sequence number that's only limited to an upper bound or a GUID, in some systems also called UUID. In the SYS(2015) related thread I already indicated some have their doubts, but I'd say it's mostly misunderstandings. Nevertheless there's always the fix to just throw out a double generated ID when encountering it.
It becomes harder if uniqueness should be guaranteed in a distributed system and not from a centralized database system. And the other case that's always hindering usage of one of these two major alternatives is specifications. If the unique id must conform to a specific format for serial numbers of products, for example, or any other norm. You can then use randomly generated strings, just always check whether they are dupllicates by chance by keeping book of them. This could even be included in the generating code keeping track of generated Ids and only returning a random result that was checked against all previous generated results. But I can give you an example of an infinite loop by recursion here, just repeat this paragraph... The problem is a generator used in a distributed system cannot make that check. Duplicates would only show in merging data from the distributed systems, not earlier.
Chriss