| Subject | Re: [IBO] Re: TIBOQuery with TDataSetProvider |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-06-27T08:23:54Z |
At 11:39 PM 25/06/2004 +0000, you wrote:
model. A stand-alone, non-networked application that uses a distributed model?
components are descendants of the VCL data access hierarchy. Insofar as
one uses the TDatasetProvider and TClientDataset components as elements of
a remote client application communicating with an application running on
the host machine, the IBO TDataset-compatible components work as
intended. They just don't work in your demo application...where you are
trying to bend the DBMS around to behave like a text file or a spreadsheet
by treating the table as a server.
Perhaps if you take a look at the demo I uploaded today (RemoteData.zip)
you'll get a clearer picture of how the n-tier model works. Notice the
almost complete absence of user code in this project. It's absent because
it isn't needed - the project takes advantage of the built-in capabilities
of the VCL and IBO components.
If you don't need n-tier, then you don't need the "noise", the
performance-flattening and the inflexibility of Borland's remote
capabilities...cut your cloth to suit the coat and stick with the
efficiency of 2-tier. Every additional layer hikes up the overhead and
yanks down the performance.
All that said, I think it could be useful for Jason to look at doing a
TIBODatasetProvider for use with n-tier projects. It would be a real
improvement to have a Provider that's aware of the "extras" that
TIBODataset inherits from the native IBO architecture - KeyLinks,
KeyFields, GeneratorLinks and others.
Helen
>Hi Walter,I'm really curious about what you are setting out to achieve with this
>
>I think I've presented the same problem in messageid 31593 (and earlier).
>The DataSetProvider generates SQL statements automatically and uses
>the access component's SQL or CommandText property. Unfortunately it
>looks as if TIBOQuery (the only choice you have) doesn't accept these
> statements.
>The Client Dataset's CommandText property lets you execute ad hoc SQL
>statements that are treated the same way as the update statements.
>
>I'm still waiting for a reaction to my question.
>I've uploaded TestDsp.zip in the Files section. Feel free to extend
>this demo with using the (failing) CommandText property.
model. A stand-alone, non-networked application that uses a distributed model?
>The demo includes dbx components for comparison.There is no comparison, though. DBX belongs to the CLX model. The TIBO*
components are descendants of the VCL data access hierarchy. Insofar as
one uses the TDatasetProvider and TClientDataset components as elements of
a remote client application communicating with an application running on
the host machine, the IBO TDataset-compatible components work as
intended. They just don't work in your demo application...where you are
trying to bend the DBMS around to behave like a text file or a spreadsheet
by treating the table as a server.
Perhaps if you take a look at the demo I uploaded today (RemoteData.zip)
you'll get a clearer picture of how the n-tier model works. Notice the
almost complete absence of user code in this project. It's absent because
it isn't needed - the project takes advantage of the built-in capabilities
of the VCL and IBO components.
If you don't need n-tier, then you don't need the "noise", the
performance-flattening and the inflexibility of Borland's remote
capabilities...cut your cloth to suit the coat and stick with the
efficiency of 2-tier. Every additional layer hikes up the overhead and
yanks down the performance.
All that said, I think it could be useful for Jason to look at doing a
TIBODatasetProvider for use with n-tier projects. It would be a real
improvement to have a Provider that's aware of the "extras" that
TIBODataset inherits from the native IBO architecture - KeyLinks,
KeyFields, GeneratorLinks and others.
Helen