Paul, As Thierry so eloquently states, VFP, as we have always known, can do virtually anything and as a development system for generating front end applications it is still an excellent tool but not recognised by many people as "main stream".
After all, why ditch your "n" years familiarity and expertise with the product for, which in most cases, could be either inferior or vastly more complicated to learn and become proficient with. Go and investigate Python, C#, F# etc. by all means but when it comes to the final analysis the end user really couldn't care less about the language your system is written in as long as it is reliable and does the job they require. Oh, don't forget that once you switch to full Client Server you can quite easily mix and match programs to generate your interface applications. Dave -----Original Message----- From: ProFox [mailto:[email protected]] On Behalf Of Thierry Nivelet Sent: 03 February 2017 14:05 To: [email protected] Subject: Re: SQL Backend Question 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] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
