Page 1 of 1

Inverse Data Type Mapping ?

Posted: Sun 19 Oct 2014 22:07
by Anachronox
Hello,

I'm looking for some function for inverse data type mapping.

Instead of sql-type-to-field-type, I need to use field-type-to-sql-type function/mapping for specific provider.

I normally use parameters in query, but in case of "keyset paging” method on SQL Server I found that emitting of parameters as DECLARE is much faster way (in terms of query speed).

Is there some way to do that in UniDAC ?

Many thanks.

Re: Inverse Data Type Mapping ?

Posted: Mon 20 Oct 2014 08:59
by AlexP
Hello,

Please describe the required functionality in more details and provide a small sample.

Re: Inverse Data Type Mapping ?

Posted: Mon 20 Oct 2014 10:16
by Anachronox
Hi Alex,

here is the example:

Code: Select all

var 
  ResultType: String;
  StringField: TStringField;
  IntegerField: TIntegerField;

function FieldTypeToSQL(Field: TField; ProviderName: String): String;
begin
  // Some magic
end;

begin
  ResultType := FieldTypeToSQL(StringField, 'SQL Server'); 
//ResultType = 'varchar(10)'

  ResultType := FieldTypeToSQL(IntegerField, 'SQL Server'); 
//ResultType = 'int'
end;

Re: Inverse Data Type Mapping ?

Posted: Mon 20 Oct 2014 10:52
by AlexP
There is no "easy" way to get Server types by Delphi types. You have to implement this functionality by yourself.

Re: Inverse Data Type Mapping ?

Posted: Mon 20 Oct 2014 11:01
by Anachronox
I'm sad, Alex :?

Does not help I've UniDAC source ?

Thank you.

Re: Inverse Data Type Mapping ?

Posted: Tue 21 Oct 2014 07:40
by AlexP
We obtain types from the server as number constants and map them to internal types in the ConvertOLEDBTypeToInternalFormat method. Then, basing on the internal types, the Delphi types are generated. Therefore, there is no "simple" way to get real text names of server fields using Delphi field types.

Re: Inverse Data Type Mapping ?

Posted: Tue 21 Oct 2014 12:01
by CristianP
I have something like this for SQL Server, MySQL, PostgreSQL and SQLite.
And I am sure there is not "one size fits all".