Hi,
Massimo, you are making things more confusing (as it happens many times).
sqlrdd from harbour com can be used as complete replacement for an
application written using dbfcdx
These is no such thing "harbour com", there is xharbour.com. Please,
feel the difference between harbour and xharbour after being so long
time on Harbour developers mailing list.
rddsql not support any index command (cdx),
Not true. And what do you mean by saying "(cdx)"? Did mean a specific
CDX structure of indexes? Why did have you said "(cdx)", but not
"(ntx)", or "(nsx)"?
1) rddsql supports indexes. Both
\harbour\contrib\rddsql\tests\arrayrdd.prg and
\harbour\contrib\rddsql\sddmy\tests\test1.prg uses indexes.
2) neither sqlrdd, nor rddsql support cdx (or ntx, or nsx).
i vote for maintain this mailing open to any info regarding knowledge
compiler,database,os
Sorry, I do not understand your the idea, but I vote for all good things
in the world.
For me f.e. it's not very clear what is the difference
between xhb SQLRDD and our RDDSQL.
Victor, please read below. It's an old text, but I deleted some
complicated parts, replaced some old names with new one hoping that it
will help to catch the main idea. If it is still not clear, please ask,
and I hope this can help to write more clear description.
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
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
