Thanks Przemek. Useful insights, they confirm my concerns. Actually, since I see no chances that we will have an open source Mediator clone any time soon, for me the best option still seems remote access, and that means GTNET. Currently you solve it on *nix servers only, but it would be very good to have this inside Harbour to move it to all platforms (well, Windows and OS/2). This probably takes less effort (which much better performance gain and no app modification) than using any of these remote database solutions.
Another thing: letodb was missing from this thread so far, and I wonder how it compares to the other alternatives. If someone has any information, it'd be a helpful addition to this thread. Brgds, Viktor On Mon, Jun 8, 2009 at 11:46 AM, Przemyslaw Czerpak<dru...@acn.waw.pl> wrote: > 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 > _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
