Clipper On Line • Ver Tópico - SQLRDD a verdade está la fora!
Página 1 de 1

SQLRDD a verdade está la fora!

MensagemEnviado: 14 Abr 2014 13:30
por Itamar M. Lins Jr.
Bom p/ quem está pesquisando se compra ou não, informação é sempre bem vinda.

https://groups.google.com/d/msg/comp.lang.xharbour/hdQvLSZ72YI/N3Mei_xpLiEJ
 wrote this post to inform the community about SQLRDD errors and the lack of support from xHarbour.com. 

I bought xHarbour Builder Enterprise in November 2013 because I needed SQLRDD.

As soon as I started using SQLRDD I found that DbrLock() / DbrUnLock() scheme is broken because DBrunlock(xRecno) releases all the locks instead of the one passed.

I posted this issue with an example in December 2013 when my subscription was still covered but my post was ignored.

I wrote to Patrick Mast in February 2014 (in the meanwhile my support was expired but my post still pending unresolved).

Patrick forwarded my question to Luiz an Marcelo Lombardo but still there was no answer.

I sent a new email to Patrick, Marcelo and Luiz in March and finally I got the following answer from Marcelo:

"Is not a bug but a SQL limitation. There is no such thing as individual lock / release in any SQL database. All locks resides in a transaction. Once transactions is committed, all locks are released. Sorry, no workaround possible."

I can't accept with Marcelo reply because locking is a FUNDAMENTAL PART of the language and a MUST HAVE for any RDD.

No information about this limitation is present neither in the website nor in the documentation.

These are the SQLRDD specifications published in xHarbour.com website:

SQLRDD allows transparent access to the most important relationary data bases of the market, ACCURATELY IN THE SAME WAY AS IF IT MAKES WITH ARCHIVES DBF.

Very little changes in the xBase source code. Only to declare the RDD, a function call to connect to the database and a substitution for the function file() for an equivalent that returns the presence of the internal archive of the database.

Then I wrote to Marcelo:

"I could be wrong, but it seems that if you are opening a transaction for each lock on a table, as soon as the first (most external) transaction is committed all the internal transaction are committed. This could be a big error.
No information on this topic is present in the documentation of SQLRDD and you should agree with me that the locking mechanism of xHarbour is a "must have" for every RDD. I'm not an expert of Relational Database but it seems to me that the only way to realize such mechanism with a DBRMS is to use a "semaphore" table (I can see that there is a table named SR_MGMNTLOCKS, maybe it was created for this scope).

And Marcelo wrote back to me :

"SR_MGMNTLOCKS was created on an attempt to simulate TABLE LOCKS, and this attempt failed."

Thus Marcelo is confirming that it is a well known problem but they neither solved it nor documented.

Marcelo also gave me wrong informations when I asked him:
 
"Does the following code work in the same way with DBFCDX and with SQLRDD?
 
dbrlock(1)
dbrlock(2)
dbrunlock(1)   <--- Does SQLRDD release also record 2 here?
 
do something with record 2
 
dbrunlock(2)"

He replied to me:

"No. It will release all in second unlock, so record 1 remains locked until second unlock is executed."

(Marcelo, let me say - with the same words you write to me - that "It seems to me that you should take a little time to learn and understand SQL, than maybe, just maybe, you will understand what I mean...")
 
After this reply I wrote to Patrick, Marcelo and Luiz:

"Patrick, it seems to me that XHarbour.com don't want to solve problems.
I can't trust XHarbour.com if you are not able to solve this problem.
I need support, I want to pay for it, but I can't pay you more money if you can't or simply don't want provide support.
Moreover now I'm also angry, because this issue was opened 4 month ago.
Solve this problem is not enought to convince me to trust in you again.
I also need a solution for the SR_setfilter() with conditional index  problem (you already have the sample), and for the
tbrowse:forcestable() problem (I can produce a sample for this last  error only if we found an agreement and when the first 2 are solved).
I will wait a positive answer about this agreement within tomorrow or  I will post on the newsgroup these errors with samples, my emails and  your answers,  and my opinion on SQLRDD and related service.
I'm sorry that we get to this point.
This is not a good way to solve problems but it's the only one you leave me."

At this Point Marcelo replied to me:

"About your sample, I will try it as soon as I can.
Please fell free to publish whatever you want on wherever you want. This is a free world.
Please understand that me, as a xHarbour.com member, will not work under any kind of terrorism threats in newsgroups, so simply go on and try to explode it as much as you can. I don't care. SQLRDD have thousands of happy users and your opinion is nothing more than that: your opinion (mainly with fragile technical arguments)."

I am very sorry to write this post because I think the xHarbour team has done a great job. I hope that this post will push them to solve these issues or, if not , it will be useful to anyone who intends to buy SQLRDD.

I think that xHarbour is a good product but SQLRDD is not compliant with RDD functionality.
My experience with xHarbour support is terrible. I waited 4 month and their answers was sometimes quite offensive:

"It seems to me that you should take a little time to learn and understand SQL, than maybe, just maybe, you will understand what I mean..."

Or

"As I said, just go ahead and do whatever you think you should do. That will never change the way SQL works, and will end up as you  exposed as someone with zero SQL knowledge."

Marcelo, I know how SQL works and that's why I expect that SQLRDD addresses this difference between DBF and DBRMS lock behavior.

We have one more bug documented by an example: SR_Setfilter() is not working with CDX conditional Indexes (indexes with a FOR Clause). Also this bug was ignored by xHarbour.com.

Moreover we have a bug on tBrowse:forcestable().
We didn't  have a sample yet, because there is no use in spending time to produce examples that are ignored.

Finally, there are some other minor bugs on how indexes are maintained but it does not worth the time to detail more.

Regards,

Roberto


Saudações,
Itamar M. Lins Jr.