Tim

would you be so generous as to the relationship between the field types defined in DB and your's please. This is what I have so far.

function GetFieldType(Fld: TField): string;
begin
 case Fld.DataType of
  ftInteger: Result := 'INTEGER';
  ftString: Result := 'VARCHAR(' + IntToStr(Fld.Size) + ')';
  ftFixedChar: Result := 'CHAR(' + IntToStr(Fld.Size) + ')';
  ftBoolean: Result := 'BOOLEAN';
  ftDate: Result := 'DATE';
  ftFloat: Result := 'FLOAT';
  ftTime: Result := 'TIME';
  ftMemo: Result := 'CLOB COLLATE "ANSI"';
  ftBlob: Result := 'BLOB COLLATE "ANSI"';
  ftGUID: Result := 'GUID COLLATE "ANSI"';
  ftDateTime: Result := 'TIMESTAMP';
  ftSmallInt: Result := 'SMALLINT';
  ftAutoInc: Result := 'INTEGER GENERATED ALWAYS AS IDENTITY (START WITH 0, INCREMENT BY 1) NOT NULL';
  ftLargeInt: Result := 'BIGINT';
  ftCurrency: Result := 'DECIMAL(20, 4)';
  ftBCD: Result := 'DECIMAL(20, 4)';
  ftBytes: Result := 'BYTE(' + IntToStr(Fld.Size) + ')';
 else Result := 'VARCHAR(' + IntToStr(Fld.Size) + ')';
 end;
end;



Roy Lambert

Roy,

<< would you be so generous as to the relationship between the field types
defined in DB and your's please. This is what I have so far. >>

No need, see the edbcomps.pas unit:

  function FieldTypeToSQL(FieldType: TFieldType; Size: Integer):
TEDBString;

Just pass 0 for the Size if you don't want the parentheses with the size
output in the resulting string.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


There's lots of interesting bits hidden around aren't there

I see for ftCurrency you're just using a standard  I would have thought a decimal 0,2 or does Delphi just translate to ftFloat?

I presume the 0 in front of a decimal means "as big as it takes"?

Roy Lambert

Tim


I feel your definition of AUTOINC is flawed (at least for my purposes of creating a table from the fields defined in the IDE). It allows nulls and if the column is used as a primary key will happily blow up My test was enter something in a string field, press the down arrow and kerbang.

Currency fields defined as a float is a bit weird (might be the same for DBISAM - I haven't tested) enter 1.2345678 and when I press enter it get reformatted to £1.23.

Roy Lambert

Roy,

<< I see for ftCurrency you're just using a standard I would have thought a
decimal 0,2 or does Delphi just translate to ftFloat? >>

ftCurrency is simply a Float field, just like it was in DBISAM.

<< I presume the 0 in front of a decimal means "as big as it takes"? >>

Yes, it's a fixed precision:

http://www.elevatesoft.com/edb1sql_approximate_numeric_types.htm

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< I feel your definition of AUTOINC is flawed (at least for my purposes of
creating a table from the fields defined in the IDE). It allows nulls and if
the column is used as a primary key will happily blow up My test was
enter something in a string field, press the down arrow and kerbang. >>

Nothing in the standard dictates that an IDENTITY column must be non-NULL.
That's why there's the GENERATE options for DEFAULT or ALWAYS for IDENTITY
columns.

<< Currency fields defined as a float is a bit weird (might be the same for
DBISAM - I haven't tested) enter 1.2345678 and when I press enter it get
reformatted to £1.23. >>

It's exactly the same as with DBISAM.  The whole currency issue is down to
legacy BDE nomenclature for float fields that are formatted for currency
values in Paradox.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>Nothing in the standard dictates that an IDENTITY column must be non-NULL.
>That's why there's the GENERATE options for DEFAULT or ALWAYS for IDENTITY
>columns.

But ElevateDB objects strenuously if a primary key is NULL.

><< Currency fields defined as a float is a bit weird (might be the same for
>DBISAM - I haven't tested) enter 1.2345678 and when I press enter it get
>reformatted to £1.23. >>
>
>It's exactly the same as with DBISAM. The whole currency issue is down to
>legacy BDE nomenclature for float fields that are formatted for currency
>values in Paradox.

Thought that might be it

Roy Lambert

Roy,

<< But ElevateDB objects strenuously if a primary key is NULL. >>

Sure, but a primary key <> identity column.  The two are completely
different things.

--
Tim Young
Elevate Software
www.elevatesoft.com