TRemoteQuery 1.1 FINAL BETA
David Berneda
100115,
[email protected]
This is the LAST BETA of TRemoteQuery and the companion server
application REMOQUE.EXE.
TRemoteQuery acts like TQBE (a derived DBDataset) but sends the query to
another machine to be executed.
Query language can be choosen between QBE and SQL.
Benefits on doing queries remotely are bigger when big tables and/or more
table joins are involved.
Every machine can act as a Query Server and Client at the same time, and
the Client can send several queries in parallel to several Servers, thus
distributing CPU power and reducing Network traffic to perform the query.
Queries can be chained using the remote answer tables, so only the last
query in the chain must transfer the results to the client machine.
Query statement can be in QBE or SQL languages.
While TRemoteQuery is waiting the Server to finish, some events are
generated to let the user decide what to do and how to take profit on this
time.
Using TRemoteQuery is completely transparent. You can program thinking
the queries will be executed locally. Even you can decide that at run-time !!!
New improvements are currently being developed, such as security, priorities,
WWW integration and cost estimation to choose the best and fastest server.
Please mail-me with suggestions, bugs, comments, summer dreams,etc
Some improvements and errors have been corrected from first BETA
version 1.0:
New in TRemoteQuery !!!
SQL statements can be used, as well as QBE language.
Params from TQuery must be translated to AddParam procedures.
Property SecondsTimeout now can be 0 (zero) meaning we want to wait indefinitely for
Server to end the Query.
Now it's possible to start several Servers on several machines. TRemoteQuery has a new
property ServerAlias that must point to the choosed server and can be changed in run-time.
Property RequestLive no longer exists as all remote queries have answer table, so aren't
"live".
If you need to attack directly to underliying tables, use a TTable component instead.
The Procedure TRemoteQuery.OpenRemoteOrLocal tries to execute the Query in the way
defined in DoRemote, if it fails, then tries to do it Locally (or viceversa).
The Procedure TCustomQBE.ExecQBE executes the query but dont returns a cursor handle.
This is useful with INSERT,UPDATE or DELETE queries, to avoid the "Cannot create cursor
handle" exception.
The AskMoreWait property.
When TRUE, a Dialog is presented to the user asking to wait more time when Timeout occur
while waiting the server to finish executing the query.
If user says NO, then a "Timeout waiting Server" exception is generated. Catch it if you want
your own timeout handling.
A new subevent is sended to OnWaiting event: rsRefreshing.
Now, TRemoteQuery polls the REMOQUE.DB to detect query completion at incrementing
intervals, thus freeing the net while the server is executing slow queries.
Every time the REMOQUE.DB is examined, a rsRefreshing subevent happens.
New in Server application REMOQUE.EXE :
The queue can be emptied in run-time.
Some errors have been corrected and processing is more solid.
Now flashes between Blue and Green when Idle, and stays Red when busy.
The queue form now shows in English.
New in DEMO application :
Query can be executed remotely or locally.
User can choose QBE or SQL language.
Query statement can be modified prior to execute the query.
User can choose which SERVER will execute the query.
New REMODLL.DLL
The DLL subdirectory has the REMODLL.DPR project.
Look at REMODLL.DPR for instructions.
Basically, REMODLL.DLL can be used to execute a query remotely from other applications
that support DLL calls (like Paradox, Excel, etc).
