--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> At 11:39 PM 25/06/2004 +0000, you wrote:
> >Hi Walter,
> >
> >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.
>
> I'm really curious about what you are setting out to achieve with this
> model. A stand-alone, non-networked application that uses a
distributed model?

Not distributed but merged. Borland provided a TLocalConnection (had
better be named TNoConnection) component to merge serverside and
clientside components in one module. So you can use TClientDataSet in
1-tier apps. I used it to make a stand-alone non-networked testdemo
just to make life easier for those interested and to extend it to a
"IBOSnap" demo in the future. I understand you regard it as being an
ugly duck already, so I removed it from the list.

>
> >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.

So? It's not that strange to use another set of components to compare
results, isn't it? Walter Ogsten had the same idea and used IBX. I
used DBX.

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.

In dataset.hlp I read that it is Jason's intention to implement the
possibility of using TClientDataSet (TDataSetProvider) with IBO.
Trying the example you made for Walter made me try setting the
TDataProvider.ResolveToDataSet to true again, and I'm embarrased to
inform you that it works, thanks very much!
Nevertheless when linked to a querycomponent, in my view only 100%
datasetprovider competability is achieved when resolving updates via
TSQLResolver works.

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.
>

Great! I never knew what to answer when people asked me what I was
doing. Now I know: I'm bending DBMS's (and I like it).

> 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.
>

Thanks again for your example. It helped me solve the problem for now,
but it isn't the model I'm working on.

> 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.
>

I need to deliver zero-configuration thin clients which don't need to
be connected via ADSL all the time when updates are done. N-tier is
the way to go.
From what I experience and what I read, it seems to me that little
people agree with you. Moreover using a powerful component like
TClientDataset in every db app model (1-, 2-, 3+ tier) is gaining ground.

> 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.
>

You can look at DataSetProvider and the ClientDataSet as a split
DataSet. Perhaps I'm mistaken, but I see similarities in IBO's
philosophy on DasaSet components (with the "extras") and part of the
functionality of TClientDataSet. From that perspective one could argue
for splitting TIB_Query (or TIBOQuery) into TIB_DataSetProvider and
TIB_ClientDataSet.

At http://www.components4programmers.com/index.htm I just saw
middleware for n-tier apps kbmMW using IBO in a demo app. I haven't
tried it yet, but for anyone interested: there's also a free version
available.

As a workaround for my problem I used the TDataSetProvider's
BeforeUpdateRecord eventhandler. I generate the SQL statements
dynamically and use TIB_DSQL to execute them. It is much more work
than the RAD way when the statements are simple. For Inserts I use SPs
mostly. For Edits unfortunately I can't use SPs, primarily because I
don't get RowsAffected back. I tried to have the SP return ROW_COUNT,
but that doesn't work when EXECUTE STATEMENT is used.
Selects are mostly done with SPs. A light TIBOCursor component instead
of TIBOQuery would be nice.