Subject Re: [IBO] TIBOQuery with TDataSetProvider
Author Walter Ogston
Helen,

I ran your test project and everything works fine. The difference is that
you are putting the dataset provider and the clientdataset in different
modules of the same application, so they are communicating within a single
process. In my setup the two components are separated by a Soap
connection, so the communication is between two processes. I have to admit
Soap is something of a black box to me, but I think the data packets get
marshalled into XML. But I would have thought the inherited TDataSet code
of TIBOQuery would take care of this, unless there is an update of TDataSet
that has not found its way into TIBOQuery yet.

Anyway, I have uploaded IBOSoap.zip to
http://groups.yahoo.com/group/IBObjects/files/ which contains a
stripped-down demo version of the project that is giving me the trouble.

Oops, I forgot to include the Readme.txt file. I'll append it to the
bottom of this letter, it isn't too long.

If you or one of the other great IBO gurus wants to tackle the problem I
will thank you. Meanwhile, I will revert my application to using TIBQuery
for the time being.

Thanks.
Walter

<Readme>
Demo Project shows strange behavior of IBOQuery connected by
TDataSetProvider to a client dataset over a SOAP connection, using
CommandText to set the SQL of the IBOQuery.

The SOAP connection in this case is mediated by Borland's WebDebugger
utility. (It uses COM to simulate a local web server, using localhost:8080)

To make it go, point IBODatabase1 and IBDatabase1 to IBLocal or any other
working IB/FB database.
After compilint, Execute pIBSoapSvr.exe to register it as a COM server.

Make sure that the database has a valid username and password, and that
LoginPrompt is set to False - otherwise the server will freeze silently -
it cannot show the login dialog.

Execute IBSoapClient.exe (from the ide). If all is working correctly a
form will appear representing the SOAP server (you can close this form to
kill the server) before the client form shows.

In the client, enter a valid sql in the upper right memo, and execute it by
clicking the button. The first time you do this, if the sql is good, you
should see a result set in the lower window.

Now change the SQL string and click the execute button again. On the code
statement Active := False; I get ERemotableException with message 'Blank
SQL Statement not allowed'.

Click the execute buttoin a third time. The Active := False statement
doesn't cause any problem
(the dataset is already inactive) but on the Active := True statement, the
old result set appears in the ClientDataSet - the query is not updated to
the new SQL.

To prove that the SOAP connection is working properly, you can change
DataSetProvider1.DataSet to IBQuery1. Make sure that IBDatabase1 is
pointing to the correct database, has a good username and password, and has
LoginPrompt = False. Now the SQL you enter will execute correctly every
time (according to my experience).
</Readme>

At 03:27 PM 6/27/2004 +1000, Helen Borrie wrote:
>Walter,
>
>At 05:23 PM 25/06/2004 -0400, Walter Ogston wrote:
> >Dear Friends,
> >
> >With D7 Ent I am using a TDataSetProvider to link TIBOQuery to
> >TClientDataset, over a SOAP connection.

<snip>

> >The first time I execute this, everything works as expected.
> >
> >Then I change the SQL string and execute this code again, and on the
> >statement Active := False; I get ERemotableException with message 'Blank
> >SQL Statement not allowed'.
> >
> >The third time, the Active := False statement doesn't cause any problem
> >(the dataset is already inactive) but on the Active := True statement, the
> >old result set appears in the ClientDataSet - the query is not updated to
> >the new SQL.
> >
> >This all worked in an earlier version using TIBQuery and TIBTransaction in
> >place of the IBO components.
> >
> >Am I doing something wrong, or failing to do something right, or is this
> >kind of thing beyond the capabilities of the IBO TDataset descendents?
>
>I don't know the score with the setup you have here - trying to set the SQL
>from the remote data module - but I've done a small working demo of a
>TIBOQuery-TDatasetProvider-TClientDataset setup using a straightforward
>setup with ResolveToDataset set True in the provider. Replace my Path
>alias with your own before you compile it. Note, "Local" in this demo
>means "local to the server", while "Remote" is the remote data module.
>
>About the only thing that seems to be a problem when using the remote
>dataset is its lack of capability to be "aware" of native IBO tricks like
>GeneratorLinks, that the TIBODataset inherits from TIB_Dataset. This makes
>inserting somewhat of PITA when one is used to IBO. Hence, I had to do a
>rude hack using a second CDS to fetch a new PK value from the generator
>(though I guess it's what VCL users are used to doing).
>
>I'm sure there will be a way to handle sending custom SQL from a
>clientdataset. Someone might have done it...
>
>Helen
>
>
>
>___________________________________________________________________________
>IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
>___________________________________________________________________________
><http://www.ibobjects.com>http://www.ibobjects.com - your IBO community
>resource for Tech Info papers,
>keyword-searchable FAQ, community code contributions and more !
>
>
>Yahoo! Groups Sponsor
>ADVERTISEMENT
>
>
>----------
>Yahoo! Groups Links
> * To visit your group on the web, go to:
> *
> <http://groups.yahoo.com/group/IBObjects/>http://groups.yahoo.com/group/IB
> Objects/
> *
> * To unsubscribe from this group, send an email to:
> *
> <mailto:IBObjects-unsubscribe@yahoogroups.com?subject=Unsubscribe>IBObject
> s-unsubscribe@yahoogroups.com
> *
> * Your use of Yahoo! Groups is subject to the
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.

/*----------------
C. Walter Ogston
ogstoncw@... Kalamazoo, Michigan
*/