--- David Johnson <d_johnson@...> wrote:

> > Who care's about a machine not on a network?
> >
> I am building for systems with intermittent and/or
> unreliable communication that must be merged as
> external conditions allow, so by your standards a
> UUID is a requirement for my purposes.

Sounds like your requirements are very similar to
mine.

> Although it would be nice, this does not "require"
> native UUID support in the database. For my
> purposes, a 36 character UUID representation
> performs nicely as the primary key on inexpensive
> WIntel hardware. (I don't keep the {}'s that M$oft
> adds to the string).

Like you I'm using a character field. For convenience
I'm keeping the {}'s. Although it really wouldn't be
hard to remove them. 38 char vs 36 char is really not
going to have a big impact though! We're talking
about around 5% increase in key size. Going from 38
down to 16 would make a substantial difference though.

So... I guess it really doesn't matter what the
Firebird dev team does. For now I'm using a 38-char
(or 36-char) key field. BTW, 38-char makes it
convenient for me to support MSSQL and Firebird for
the prototyping I'm doing right now. I intend to do
this for a while until I'm certain that I'll stick
with Firebird. In the end it comes down to how the
databases perform. If Firebird performs well enough
then I'll keep it. :-) Firebird is proving to be a
bit hard to deploy at this stage... Since I'm not on
site I can't troubleshoot these issues but that's
another subject altogether...

Cheers,
Kevin.


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com