Hi,
RDDSQL can make a very nice one-way interface to SQL DBs.
I'm not sure what you mean by saying "one-way". Do you mean it is a read
only? The answer is: Yes and No.
It does not generate hidden queries. It means, that
SOMEFIELD := value
will not generate SQL query and execute "UPDATE table SET
SOMEFIELD=value WHERE ID=someid". You will have to generate and execute
these queries yourself using:
RDDINFO(RDDI_EXECUTE, "UPDATE table SET ...")
But field assignment still works! The cached query result will be changed.
? SOMEFIELD
will print the new field value. You can even use DBAPPEND() on RDDSQL.
It will append one more row (IN CACHE of cause, not in SQL database).
RDDSQL without any SDD* driver can be used as a kind of arrayrdd, see
rddsql/tests/arrayrdd.prg.
The only thing is required to make application using RDDSQL to be a
read-write application. You should track changes of workarea cache and
"commit" it using RDDI_EXECUTE manually.
My idea (still not implemented) is to do some helper function to iterate
through appended or modified record. After a browse exits you iterate a
workarea and generate UPDATE/INSERT queries to real SQL server.
The other choice is to generate SQL queries right after you press
[Enter] in you record edit form of the browse. In this case you do a
"commit" right after data is entered. I'm using the browse that
implements this approach, I've almost forgot about UPDATE/INSERT
queries. I do not have them in my application code, it is in my GUI
library sql browse internals. (That's actually the reason, why I still
do not implemented some modified records iteration helper functions.)
Regards,
Mindaugas
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
