>
> Massimo, you are making things more confusing (as it happens many times).
Sorry for my confusing and for my bad English
>> 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.
yes
>
>> 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).
with sqlrdd and mediatior you can migrate with 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 table
IMO rddsql is not usable for port existing dbfcdx application because
it not support alle the functionality of indices like order bags and
tags.for example are not supported set order to ,recno(), deleted(),
seek
Instead is good for creating new application
I think that in a new application your way is right because help think
sql instead clipper
in your sddmy\test1 you not write the clipper way based on dbcreate,append
? RDDINFO(RDDI_EXECUTE, "DROP TABLE country")
? RDDINFO(RDDI_EXECUTE, "CREATE TABLE country (CODE char(3), NAME
char(50), RESIDENTS int(11))")
? RDDINFO(RDDI_EXECUTE, "INSERT INTO country values ('LTU',
'Lithuania', 3369600), ('USA', 'United States of America', 305397000),
('POR', 'Portugal', 10617600), ('POL', 'Poland', 38115967), ('AUS',
'Australia', 21446187), ('FRA', 'France', 64473140), ('RUS', 'Russia',
141900000)")
The problem of rddsql is due do difficult of understand what can't be
done...or can't be done only when you have good sql control. Naturally
not for you that have made it.
>>> 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.
Good having updated info
>
>
> Regards,
> Mindaugas
> _______________________________________________
> Harbour mailing list
> [email protected]
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
Massimo Belgrano
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
