Massimo Belgrano wrote:
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
Hi,
yes RDDSQL is not a tool for straight conversion of DBFCDX applications
into SQL world. But I'd rather not call applications converted to SQL
using some "transparent" conversion RDD "the real SQL applications".
Let's take a simple case. We want to make a report of total amount of
items purchased. It will look in DBF code:
DBCREATE("tmp", {{"CODE", "C", 16, 0}, {"TITLE", "C", 100, 0},
{"AMOUNT", "N", 12, 2}},, .T., "tmp")
INDEX ON CODE TAG code TO tmp
USE purchase NEW // fields: INVOICE, CODE, AMOUNT, etc.
DO WHILE ! EOF()
IF ! DELETED()
IF ! tmp->(DBSEEK(purchase->CODE))
tmp->(DBAPPEND(), CODE := purchase->CODE)
ENDIF
tmp->AMOUNT += AMOUNT
ENDIF
DBSKIP()
ENDDO
DBCLOSEAREA()
USE items NEW // fields: CODE, TITLE, etc.
OrdSetFocus("code")
DBSELECTAREA("tmp")
DBGOTOP()
DO WHILE ! EOF()
items->(DBSEEK(tmp->CODE, .F.))
TITLE := items->TITLE
DBSKIP()
ENDDO
items->(DBCLOSEAREA())
// Here we have report. We can print it
DBGOTOP()
DBEVAL({|| QOUT(CODE, TITLE, AMOUNT)})
All above in REAL SQL world will look:
DBUSEAREA(.T.,, "SELECT CODE,SUM(AMOUNT) AS AMOUNT FROM purchase
GROUP BY CODE ORDER BY CODE LEFT JOIN items ON
items.CODE=purchase.CODE", "tmp")
// Here we have report. We can print it
DBEVAL({|| QOUT(CODE, TITLE, AMOUNT)})
Please, try imagine how the first version of application work under RDD
that help to do a "transparent" DBF to SQL conversion. That is speed,
server load, correctness, etc.
For example,
items->(DBSEEK(tmp->CODE, .F.))
TITLE := items->TITLE
will cache let's say 100 records of items table (to make things work
"faster"), but only the first one is necessary.
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
If "port existing dbfcdx application" means, make application to work
using SQL server with as little changes as it possible, then for sure
RDDSQL is not for that purpose. But I would rather not call such
application a SQL application at all.
My practice shows, that application can be easily rewritten to SQL style
using RDDSQL by moving many logic to query text. The only issue is
browse object. It should be rewritten to use a small queries to display
a data from a large datasets. The internals of browse should generate a
query to display content after each PgUp, PgDown is pressed, etc.
Regards,
Mindaugas
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
