Hi Mindaugas, >> 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 ...")
I see, so you can even update the table in DB, although this isn't part of any sort of virtualization AFACS, it just passed the command to through the SDD. > 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. Okay, I realized that. > 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. Or, RDDSQL itself may track these changes and automatically generate the UPDATE/INSERT requests to SQL server. Given that the recordset can be the result of any kind of queries, this doesn't seem to be doable (seemed a good idea for a few minutes though :). > 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.) I see. Overall to me RDDSQL looks like a proper and common wrapper implementation to our existing and not very much compatible solutions: HBPGSQL, HBMYSQL, HBFBIRD and HBODBC. And instead of direct API calls and Harbour classes it makes this functionality accessible through the existing Harbour db functions as an RDD. I hope my picture is clear now, many thanks for your valuable input. Brgds, Viktor _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
