creating a guid using string theory

[terryd]

Hi Bruce
NTWS725 StringTheory191
Not really a Nettalk question but since this comes up when creating a guid using string theory in my webservers maybe you can help.

Whenever I create a new record i create a guid by calling a source procedure which contains this line:

 RETURN st.Random(16,st:Lower + st:Number)

I would expect this to create a 16 character string with a combination of lowercase and numbers
However it just seems to be returning lowercase characters
Below is an extract from a table created using this procedure
"Documentid"
"ccdgtholabhrbrna"
"mxkayecctmnzubsr"
"vsckltobkkcaqlpw"
"kgzjpagqrmeksoxf"
"ilwgxhwgnbiixzta"
 "gygmgicwejxalxdq"

Is my st.Random call correct?

[Stu]

Hey Terry,

The st.Random() call is right (I use

Code: [Select]

st.Random(20,st:Upper+st:Lower+st:Number)).

But to get the string, you'll want to use st.GetValue(), ie

Code: [Select]

rec:GUID = st.GetValue()

At least, that's what I've got in my code.

But looking at the docs (http://capesoft.com/docs/StringTheory/StringTheory.htm#stRandom), I see that you CAN use the call.

Nice. Learn something new every day.

[Bruce]

http://search.dilbert.com/comic/Random%20Number%20Generator

[Bruce]

I ran a test here, using that line, and I seem to get back values including digits.
Perhaps your priming is not actually using that function?
maybe put a debugview, or stop statement in there just to make sure.

cheers
Bruce

[TimR]

If using MSSQL you can also use this statement to generate a guid.

select newid()

Off topic a bit, but I'm hoping if I write it down I may actually remember it when I need it.

[terryd]

Thanks Bruce, Tim
I found my issue. Previously I had coded into the priming embed point without the number attribute (before it was available). I then created the little source procedure and called it directly from the template priming tab as CreateGUID(''). Because the embed point is after the template priming point it overrode the value passed back from the source procedure.

Tim
Currently I prefer what i am doing since should I convert this app at a later stage to SQL my code wouldn't change (i.e. I wouldn't end up doing exactly what I did here ;-))