On 12/13/2003 08:33:52 AM "Martijn Tonies" wrote:

>
>> >> the same for what should really be two distinct types (text and

GUID),

>> >> then we run into difficulties.
>> >
>> >Can't you get the GUID as a string and convert it on the
>> >client/application side?
>>
>> As I see it, the problem is making the client know whether it has a

GUID

>> or a CHAR value. Then we can talk about how to convert it.
>>
>> Am I missing something?
>
>Perhaps I am :-)
>
>Isn't your client aware of any datatypes? That is, if I would be
>selecting from a database, I know that certain columns are Integer
>and certain columns hold a GUID (or are the GUID datatype).
>If I know it holds a GUID, I could adjust it a little so that it converts
>a char value into a GUID in my code, right?

The client is aware of datatypes it receives. It knows when it is
receiving an INT, when it is receiving a CHAR(16), and when it is
receiving a GUID. If we now change GUIDs to CHAR(16)s, we have to make the
client decide whether it is really working with a CHAR(16), or if it's
really working with a GUID.

How do we do that? The only way to do that reliably is to query the
database somehow to see what type of field we have. That means another
trip to the database every time we run across a CHAR(16), with a
performance hit. It also means that the client and the server (using an
OOP term) become much more tightly coupled. Currently they are properly
decoupled. So we lose both practically and theoretically. The latter will
surely have ramifications later.

I have suggested to the team I'm working with that the interface
automatically consider and field with CHAR(16) CHARACTER SET OCTETS a
GUID. The initial reaction I received was that this would be dangerous for
anyone else using the database, and the database interface would become
implementation specific. We should keep the idea, in case we can't find a
better one.

Steve Miller
Language Software Development
SIL International

[Non-text portions of this message have been removed]