What is the difference between xHarbour SQLRDD and Harbour RDDSQL. ?

CCH : An interesting post by Mindaugas Kavaliauskas on 7th June 2009 "Harbour Project Main Developer List."

RDDSQL implements accessing SQL query result via RDD interface, i.e. you write a SQL query and you are able to reach result of a query using FIELDGET(), DBSKIP(), DBGOTO(), etc. All these function calls does not generates additional queries, it will operate on result
of the query you've asked for.

RDDSQL does not try to be a "transparent" sollution for DBF to SQL move, and does not try to emultate DBF specific operations (ex., DBAPPEND(), DBDELETE(), OrdCreate(), FLOCK(), etc.) via some unnatural SQL operations.

I want to discuss this in more detail. Many current RDDs for accessing SQL servers (ex. SQLRDD from xHarbour.com) tries to make a feeling you are working with DBF file, but not with SQL database.

SQL server does not support many features, ex. RECNO(), deleted flag, file locks, record locks. These RDDs are emulating these features to make feeling of DBF. DELETED() function is emulated by creating additional table columns to store delete flag. Some "hidden system"
tables are used to register locking operations and emulate record and file locks in DBF style. The idea of SQL query is also lost. If you do a simple loop

DBUSEAREA(, "select * from my_table")
DO WHILE ! EOF()
somefunc( FIELD->some_sql_field )
DBSKIP()
ENDDO

"Transparent" DBF to SQL solutions usually will read SQL rows in portions, let's say 100 records per query. So, hidden queries are generated. If another client issues UPDATE query between these hidden queries, it can happen, that the same row will be fetched the second time, or does not fetched at all.

The idea of RDDSQL is different. It does not make hidden queries. All queries should be made explicitly by programmer. RDDSQL gives access to query result via RDD interface, it does not tries to emulate DBF and be "transparent" solution for DBF to SQL migration. If you
call:

DBUSEAREA(, "select * from my_table")

the entire query (it could contain millions of records, so be carefull!) will be cached.


The features of RDDSQL approach are:
- It's possible to access SQL database of other applications. Other
applications usualy does not follow agreement of "transparent" SQL
drivers about additional DELETED column, _RECNO in the end of index
expression, etc. Access of SQL database of another applications is
sometimes not possible.

- It's query oriented. That means a simple DO WHILE ! EOF() loop will iterate each records once and only once. This is not true for "transparent" DBF to SQL solutions.


Regards,
Mindaugas