Hi Paul,
I wish I could understand your question…
To me, the user interface and the database back-end are 2 completely separate concerns…
The only 2 factors I see influential are: - whether you use buffering and/or transactions or not: you'll get a cancel button or not - how you let the user navigate into the data: whether sequentially (eg using a VCR toolbar) or directly through search / filter.
Whether you can use VFP or SQL data has no influence on these 2, as both are equally feasible with both database.
The 'keystroke saves' principle comes from Apple AFAIK and it's practical in come cases, not in other cases, just like row buffering.
An interesting tool to smoothly slide from/mix VFP and SQL data is CursorAdapter where you can easily leverage an application-wide business logic and implement specific data access tricks for each back end. It's a kind of programmatic view either local or remote.
To summarize my view, VFP throws no limitation on the way you access data, even compared to modern 'standard'. Its only peculiarity is that it's been the same for 10 years.
Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/
Le 02/02/2017 à 15:54, Paul H. Tarver a écrit :
Ok, I've lurked here long enough. I've been subscribed to this list for several months and I have thoroughly enjoyed the questions and answers that have come through during that time. I'm even a little star-struck when I see the names of Foxpro experts that I have depended upon for years to help educate me to be a better Foxpro programmer. Thank you all for all you do in this list group. Now it is time for me to ask what is probably going to sound like a dumb question coming from someone who has been using Foxpro since Foxlan but I figure I have nothing to lose here and everything to gain.
For the past few years I have been honing my skills as a developer of data interfaces and until recently, the few full-fledged data entry projects I've build relied upon native Foxpro dbf files. However, my interface work has been depending more and more upon using SQL pass-through language to issue queries against various SQL backend systems and I have been pretty successful at retrieving data from various systems and then re-formatting that data for other uses.
For a while now, I've been contemplating building a data-entry and maintenance system from the ground up that depends completely upon using a SQL database (Firebird, MySQL, MS SQL, Postgres or something similar). My problem is that I have all these data handling classes built into a couple of simple toolbars that I can drop on form and provide the standard Add, Delete, Undo, Save and Exit functionality as well as a vcr toolbar to skip between records. These tools include all of the code necessary to detect changes enable various buttons based on conditions, etc. stuff we are all familiar with.
Now I'm trying to wrap my head around the whole concept of changing the way I depend upon Foxpro to handle much of the behind the scenes table activity and create a new user interface that conforms to the how SQL works while maintaining as much of the familiar functionality I'm so happy with in Foxpro.
Does anyone have any recommendations for where I should go to learn more about the best practices for developing user interfaces that work efficiently with SQL backends, and what do I need to know about how to collect data and insert it into the sql tables, detect user changes to flag for saving data. In some software they seemed to have ditched the Add, Delete, Undo, Save, Exit concept to just save everytime there is keystroke. And in other systems, they keep parts of that old style of user interaction. Are there any libraries that can be purchased or downloaded to handle some of the behind the scenes data manipulation for SQL that I can use to learn how this stuff should work.
For something that seems to be easy, I'm having a hard time letting go of my 20+ years of doing things the Foxpro way to make the transition.
Any thoughts?
Paul H. Tarver Tarver Program Consultants, Inc.
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]