On Mon, 08 Jun 2009, Szak�ts Viktor wrote:
Hi,
> I see. Overall to me RDDSQL looks like a proper and common wrapper
> implementation to our existing and not very much compatible solutions:
> HBPGSQL, HBMYSQL, HBFBIRD and HBODBC. And instead of direct
> API calls and Harbour classes it makes this functionality accessible
> through the existing Harbour db functions as an RDD.
What gives some additional possibilities not available in above libraries.
F.e. after fetching the query you can use COPY TO to transfer results to
any other RDDs or export them to CSV or SDF files.
There is yet another important issues with remote RDDs which tries to fully
emulate DBF* RDDs: synchronization mechanism, It not trivial way to well
implement it. F.e. in ADS RDD for years there was no explicit lock inside
dbAppend(). It means that newly added records were automatically unlocked.
So this code:
func copyRec( nRec, cNewCode )
LOCAL nAmount, nNewRec
dbAppend()
FIELD->CODE := cNewCode
nNewRec := recNo()
dbGoTo( nRec )
nAmount := FIELD->AMOUNT
dbGoto( nNewRec )
FIELD->AMOUNT := nAmount
dbUnLock( nNewRec )
return
was not well synchronized in ADS* RDDs because after dbGoTo( nRec )
lock on nNewRec was automatically removed.
In this case as workaround programmer can easy change the order of
instructions but it's not structural solution and in big applications
it may introduce very serious bugs hard to locate and fix. Just simply
basic synchronization mechanism was not working as it should and there
was not visible effect of the problem. Just simply sometimes application
was making some things which should not be allowed, f.e. two stations
started to make some exclusive operation. For me it's critical bug if
programmer does not know about such Clipper incompatible behavior and
the whole code was not designed to work with it.
In SQL based RDDs the problem is deeper. ADS gives API which allows to
emulate Clipper DBF based RDDs quite well. SQL RDBMS not and it has to
be emulated by RDD author. F.e. Mediator uses its own server common for
all clients to cache queries and give synchronization layer between
mediator clients so locks are visible only between them and do not effect
main tables. It quite simple and efficient solution and AFAIK it gives
quite well emulation of DBF* RDDs behavior. But it needs more complicated
installation. Except the part linked with final application it's necessary
to install mediator server and connect to RDBMS indirectly by this server.
I have no idea how synchrinization problems was resolved in SQLRDD from
xHarbour.com. It's client only solution and I do no see any easy way to
make it well without introducing some anomalies like above example in
older varsion of ADS* RDDs and without killing the performance.
Unfortunately recompiling the application and running it it's not enough
to answer that all is correct and we do not have some race conditions
inside synchronization mechanism. Personally here I would prefer open
source solution to verify it myself.
For many people important is also final performance. And here RDDs which
use SQL RDBMS and tries to fully emulate DBF* RDDs should be tested with
final application.
I'm working with *nixes and all my applications are executed remotely and
access tables locally on server side only. It gives extremely fast results.
Unreachable for any other remote access, f.e. using ADS which is also quite
fast for remote access - much faster then Mediator and SQLRDD.
When I tried to used Mediator with one of my performance test (remote
access to application which locally used mediator server and PostgreSQL)
then it was 30 times slower native DBF* access. Of course if you compare
it to accessing table via network then the difference has to be much smaller
and on older slower networks Mediator is faster.
I cannot say anything about SQLRDD - I haven't tested it but for me it's
impossible to keep acceptable performance using client only solution which
tries to fully emulate DBF* RDDs as long as final RDBMS does not support
directly all necessary resources like ADS.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
