Subject | Re: [IBO] TIB_Query, how find out fields Datatype? |
---|---|
Author | Helen Borrie |
Post date | 2008-01-12T15:38:02Z |
At 10:58 PM 12/01/2008, Gerhard wrote:
It appears that you *need* these TField objects for some things, in order to have a persistent layer to provide a common denominator for working with data types from all kinds of data sources, each with its own particular set of native data types. "Native IBO" (the TIB_* components) is "native to Firebird and IB". It doesn't have (and has no reason to have) that persistent layer, since it's a dedicated interface to the Firebird/IB API and not other DB engines or DM layers.
In short, the TIBO* components are just what you need, precisely *because* they give you access to the VCL's persistent layer. With all of this extra overhead, of course there is a performance cost.
You *can* use native IBO and the TDataset-compatible components together in your application. The fact that, for some things, you want to use the VCL's persistence layer, does not preclude you from using the native IBO components for the application overall. You can have TIBOQueries there, alongside TIB_Queries. You can even assign a TIB_Dataset's current state to a TIBOQuery (using AssignSQLWithSearch)...
Helen
>Till now i normally used only the TIBODataset (TIBODatabase,[ .. snipped first part - use a separate thread for this ... ]
>TIBOQuery, and so on ..)
>i tried also to change to TIB_Query.This turns your original question around. What you really wanted to ask was how you could create TField objects from TIB_Column objects while avoiding the performance overhead imposed by TField objects.
>
>Now, i run a lot of incompatibilities in my working source code, like
>BLOB handling (fixed, using TBLOBfield now), and now the FieldType thing.
>
>Your SQLType can help, but how i can find out this types?
>ftCurrency, ftBCD, e.g.?
>With DIBOQuery i could use:....
>
>ds:= result.newDataset;
>for i:= 0 to q.Fields.Count - 1 do begin
>fname:= q.Fields[i].FieldName;
>ds.FieldType[fname]:= get_rtc_fieldtype(q.FieldDefs.Items[i].DataType);
>ds.FieldSize[fname]:= q.fielddefs.Items[i].Size;
>end;
>
>i need it to convert fieldtypes e.g. in my remotefunctons with rtc, like:
>
>const
> RTC_DB2FIELD_TYPE: array[TFieldType] of TRtcFieldTypes = ( etc.)
>I need this very often, therefore and other reasons i usedHmmm, perhaps a little faster, but 10X? If so, I don't think you are comparing apples with apples.
>till now TIBOQuery.
>
>My tests shows that a big advantage from TIB_Query is: it is very
>fast. I think more as 10 times faster as TIBOQuery.
It appears that you *need* these TField objects for some things, in order to have a persistent layer to provide a common denominator for working with data types from all kinds of data sources, each with its own particular set of native data types. "Native IBO" (the TIB_* components) is "native to Firebird and IB". It doesn't have (and has no reason to have) that persistent layer, since it's a dedicated interface to the Firebird/IB API and not other DB engines or DM layers.
In short, the TIBO* components are just what you need, precisely *because* they give you access to the VCL's persistent layer. With all of this extra overhead, of course there is a performance cost.
You *can* use native IBO and the TDataset-compatible components together in your application. The fact that, for some things, you want to use the VCL's persistence layer, does not preclude you from using the native IBO components for the application overall. You can have TIBOQueries there, alongside TIB_Queries. You can even assign a TIB_Dataset's current state to a TIBOQuery (using AssignSQLWithSearch)...
>Sorry about this very long post.Try to keep separate topics in separate threads. I suggested to you in private email that you raise your connection pooling topic in the list for eyeballing by Jason. The chances of it getting noticed are very slim if you just top-post it onto an existing thread with an unrelated Subject...especially so at the moment, as Jason has very limited access to the Internet.
Helen