Hi Brian,

>>GetColValue does not allow the application to specify the type of the
>>returned value. All we have to go on, is the server datatype. If that is
>>the same for what should really be two distinct types (text and GUID),
>>then we run into difficulties.
>
>Those who know more about this, please correct me if I'm wrong, but would

it

>work to:
>
>CREATE DOMAIN "UNIQUEIDENTIFIER" AS CHAR(38) NOT NULL;
>
>Would the the datatype in this case be returned as CHAR(38) or as
>UNIQUEIDENTIFIER?

Another colleague put it this way:

----
In Firebird you can define a custom datatype in the following manner but
it is more of an alias than a new datatype (it is a Domain in the true
database design sense).

CREATE DOMAIN GUID AS
CHAR(16) CHARACTER SET OCTETS
COLLATE OCTETS

then you can add the field as

ALTER TABLE NEW_TABLE
ADD NEW_FIELD_3 GUID

However you still end up with a field datatype of CHAR(16) CHARACTER SET
OCTETS.

I don't believe this would help you anymore than what you have now (it
does make the conversion from SQL-Server structure easier for me for
datatype mappings).
----

>We'll be struggling with this at my office at some point in the not too
>distant future as well.

I just sent off a proposal to my colleagues that might work for us.
Because we will be working with exotic scripts and alphabets, we use
Unicode data types, which in SQL Server is NVARCHAR(x) and NTEXT. In
FireBird, these data types become VARCHAR(x) CHARACTER SET UNICODE_FSS and
BLOB SUB_TYPE TEXT, respectively. We don't have any text stored in (SQL
Server) NCHAR or CHAR fields. Therefore I'm proposing we use the CHAR
datatype for our GUIDs.

A bit of a hack, but it should work for us. I'm open to better
suggestions.

Steve Miller
Language Software Development
SIL International

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