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 ---
Hello Paul,
Welcome to the fold. Like you - I've been working w/Fox since Foxbase+. Where I work - they have been trying to phase out all the old FoxPro systems (which are all currently VFP 9 systems) - and replace them with new systems based upon VB or C# and .Net. As it is - the core systems that were/are still in use (one of those systems was JUST Phased out to a new system yesterday - sadly it was a system I supported but I'm not involved with the new replacement system) - all have SQL as the main data files - although processing does use temp DBF files.
I suspect that some here may suggest using something else to do development - like C# and .Net or some such tech. Will be interesting to see what other folks say. Although, I suspect that for you this late in the game - it may not make such great sense to completely switch to a newer tech!
Regards, Kurt Wendt Senior Systems Analyst
Tel. +1-212-747-9100 www.GlobeTax.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: Thursday, February 02, 2017 9:54 AM To: profoxtech@leafe.com Subject: SQL Backend Question
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]
Paul, No problem you asking here and you will get many types of feedback. I slightly digress from Kurt's diagnosis as I am sure many on here will. We are and have been going through a transition from legacy VFP data containers onto Microsoft SQL and although it is a big job we haven't had to resort to C# or any of the other languages Python etc... VFP is still a great tool to do the front end processing and visualisation layer in projects despite maybe being past its prime and it certainly is as quick in being able to generate front ends even with fancy newstyle looks if you incorporate all the addons that have been developed over the years.
Personally I took time out to develop a set of classes that allow me to run multiple SQL sessions in multiple forms at the same time and we have used them extensively. It takes all the heavy lifting out of SQL data manipulation and leaves you, the developer to concentrate on what VFP does best!!
Mike from MBS has been using MySQL as a back end for years and now everything we do is client server so ask away...
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: 02 February 2017 14:54 To: profoxtech@leafe.com Subject: SQL Backend Question
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]
This discussion brings back memories :)
Bob Lee
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Thursday, February 2, 2017 7:59 AM To: profoxtech@leafe.com Subject: RE: SQL Backend Question
Paul, No problem you asking here and you will get many types of feedback. I slightly digress from Kurt's diagnosis as I am sure many on here will. We are and have been going through a transition from legacy VFP data containers onto Microsoft SQL and although it is a big job we haven't had to resort to C# or any of the other languages Python etc... VFP is still a great tool to do the front end processing and visualisation layer in projects despite maybe being past its prime and it certainly is as quick in being able to generate front ends even with fancy newstyle looks if you incorporate all the addons that have been developed over the years.
Personally I took time out to develop a set of classes that allow me to run multiple SQL sessions in multiple forms at the same time and we have used them extensively. It takes all the heavy lifting out of SQL data manipulation and leaves you, the developer to concentrate on what VFP does best!!
Mike from MBS has been using MySQL as a back end for years and now everything we do is client server so ask away...
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: 02 February 2017 14:54 To: profoxtech@leafe.com Subject: SQL Backend Question
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]
2007 or thereabouts Bob!!
Problems never change I guess!
Hope you are keeping well.
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Bob Lee Sent: 02 February 2017 17:15 To: profox@leafe.com; profoxtech@leafe.com Subject: RE: SQL Backend Question
This discussion brings back memories :)
Bob Lee
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Thursday, February 2, 2017 7:59 AM To: profoxtech@leafe.com Subject: RE: SQL Backend Question
Paul, No problem you asking here and you will get many types of feedback. I slightly digress from Kurt's diagnosis as I am sure many on here will. We are and have been going through a transition from legacy VFP data containers onto Microsoft SQL and although it is a big job we haven't had to resort to C# or any of the other languages Python etc... VFP is still a great tool to do the front end processing and visualisation layer in projects despite maybe being past its prime and it certainly is as quick in being able to generate front ends even with fancy newstyle looks if you incorporate all the addons that have been developed over the years.
Personally I took time out to develop a set of classes that allow me to run multiple SQL sessions in multiple forms at the same time and we have used them extensively. It takes all the heavy lifting out of SQL data manipulation and leaves you, the developer to concentrate on what VFP does best!!
Mike from MBS has been using MySQL as a back end for years and now everything we do is client server so ask away...
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: 02 February 2017 14:54 To: profoxtech@leafe.com Subject: SQL Backend Question
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]
More like 2003 I think - :) the Fox Talk articles and Prague But I moved back to LA a few years back.. Love it.
Bob
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Thursday, February 2, 2017 9:17 AM To: profoxtech@leafe.com Subject: RE: SQL Backend Question
2007 or thereabouts Bob!!
Problems never change I guess!
Hope you are keeping well.
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Bob Lee Sent: 02 February 2017 17:15 To: profox@leafe.com; profoxtech@leafe.com Subject: RE: SQL Backend Question
This discussion brings back memories :)
Bob Lee
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Thursday, February 2, 2017 7:59 AM To: profoxtech@leafe.com Subject: RE: SQL Backend Question
Paul, No problem you asking here and you will get many types of feedback. I slightly digress from Kurt's diagnosis as I am sure many on here will. We are and have been going through a transition from legacy VFP data containers onto Microsoft SQL and although it is a big job we haven't had to resort to C# or any of the other languages Python etc... VFP is still a great tool to do the front end processing and visualisation layer in projects despite maybe being past its prime and it certainly is as quick in being able to generate front ends even with fancy newstyle looks if you incorporate all the addons that have been developed over the years.
Personally I took time out to develop a set of classes that allow me to run multiple SQL sessions in multiple forms at the same time and we have used them extensively. It takes all the heavy lifting out of SQL data manipulation and leaves you, the developer to concentrate on what VFP does best!!
Mike from MBS has been using MySQL as a back end for years and now everything we do is client server so ask away...
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: 02 February 2017 14:54 To: profoxtech@leafe.com Subject: SQL Backend Question
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]
+1 - and a few of us have made detailed suggestions, which are in Ed's Archives.
On 02-Feb-2017 10:45 PM, Bob Lee wrote:
This discussion brings back memories :)
Bob Lee
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Thursday, February 2, 2017 7:59 AM To: profoxtech@leafe.com Subject: RE: SQL Backend Question
Paul, No problem you asking here and you will get many types of feedback. I slightly digress from Kurt's diagnosis as I am sure many on here will. We are and have been going through a transition from legacy VFP data containers onto Microsoft SQL and although it is a big job we haven't had to resort to C# or any of the other languages Python etc... VFP is still a great tool to do the front end processing and visualisation layer in projects despite maybe being past its prime and it certainly is as quick in being able to generate front ends even with fancy newstyle looks if you incorporate all the addons that have been developed over the years.
Personally I took time out to develop a set of classes that allow me to run multiple SQL sessions in multiple forms at the same time and we have used them extensively. It takes all the heavy lifting out of SQL data manipulation and leaves you, the developer to concentrate on what VFP does best!!
Mike from MBS has been using MySQL as a back end for years and now everything we do is client server so ask away...
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: 02 February 2017 14:54 To: profoxtech@leafe.com Subject: SQL Backend Question
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]
Hi Paul:
There are many options available, and all depends on what type of support you need (Microsoft?, Community?, 3rd.party?), may be the type of application and how much you want to $pend in the technology/tools (privatative tech/tools, Open Source tech/tools or a mix).
If you want it to be desktop, and do not mind distributing in every user PC, then you can use .Net, Python, Java, xHarbour and some others.
If you want web-based because of a centralized distribution on the intranet and let open the possibility of using it from Internet, then you can use Angular2, NodeJS, React, PHP, Python and others. Specially React (used by Facebook) have a good performance and virtual DOM (something like VFP's Table Buffering)
I did not yet made any migration between technologies, but this is what I see around and what I've read about too.
2017-02-02 15:54 GMT+01:00 Paul H. Tarver paul@tpcqpc.com:
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]
There is also Lianja which would let you leverage existing VFP code.
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]
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:profox-bounces@leafe.com] On Behalf Of Thierry Nivelet Sent: 03 February 2017 14:05 To: profox@leafe.com 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]
Go web based UI and from there you can pick any backend for data you want.
Generating UI for desktop is so limiting for your users last year, this year and the future. Just saying. I am looking at having all my UI have to work across iPad and cell phones. Because it is information that we are presenting. It isn't required to be at a user's desk to suddenly have value.
On Thu, Feb 2, 2017 at 8:54 AM, Paul H. Tarver paul@tpcqpc.com wrote:
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]
I agree on the web-front. If you have many users in Intranet infrastructure, you save a lot of money not needing to maintain every desktop installation, and not only this, viruses are more controlled too, because in the worst case you just reinstall a minimal working configuration (Windows-AV-browser-Office) and that's it.
The only case when may be better a desktop app, in my opinion, is when you need some processing that can't be done on the server, or for CAD or some utils.
I love desktop apps, but in latest years (ok, may be more) I found myself trying to use web apps for anything that I need to use when connected to Internet, and even without Internet, an Intranet is the minimal that any office have.
In the last 10 years many web apps are almost equal than the equivalent desktop ones, at window level, UI and power.
But, again, I see this kind of decision more dependent on the amount of final users, the kind of app and what the need is about scaling, connectivity, mobility, etc.
2017-02-03 15:56 GMT+01:00 Stephen Russell srussell705@gmail.com:
Go web based UI and from there you can pick any backend for data you want.
Generating UI for desktop is so limiting for your users last year, this year and the future. Just saying. I am looking at having all my UI have to work across iPad and cell phones. Because it is information that we are presenting. It isn't required to be at a user's desk to suddenly have value.
On Thu, Feb 2, 2017 at 8:54 AM, Paul H. Tarver paul@tpcqpc.com wrote:
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]
For those who are interested in *responsive web apps*, below is a video showing a Web App created with FoxInCloud from an existing 'legacy' VFP app.
FoxInCloud V 2.24 (due to release on 02/15) integrates Bootstrap and generates Bootstrap-aware HTML forms/pages based on the original VFP form design (IOW how controls are geometrically laid out on the form surface)
FoxInCloud automates the whole HTML/CSS/JS dynamic generation, only some additional CSS was provided by a designer to make main buttons, pages and transition more 'sexy'.
The app's author continues his evolutions: any change in the form layout will be reflected when HTML is generated at next server startup.
(I'm not very familiar with Youtube privacy settings, so please let me know if you can access the video)
Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/
Le 03/02/2017 à 15:56, Stephen Russell a écrit :
Go web based UI and from there you can pick any backend for data you want.
Generating UI for desktop is so limiting for your users last year, this year and the future. Just saying. I am looking at having all my UI have to work across iPad and cell phones. Because it is information that we are presenting. It isn't required to be at a user's desk to suddenly have value.
On Thu, Feb 2, 2017 at 8:54 AM, Paul H. Tarver paul@tpcqpc.com wrote:
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]
Access OK here in the UK Thierry
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Thierry Nivelet Sent: 03 February 2017 15:27 To: profox@leafe.com Subject: Re: SQL Backend Question
For those who are interested in *responsive web apps*, below is a video showing a Web App created with FoxInCloud from an existing 'legacy' VFP app.
FoxInCloud V 2.24 (due to release on 02/15) integrates Bootstrap and generates Bootstrap-aware HTML forms/pages based on the original VFP form design (IOW how controls are geometrically laid out on the form surface)
FoxInCloud automates the whole HTML/CSS/JS dynamic generation, only some additional CSS was provided by a designer to make main buttons, pages and transition more 'sexy'.
The app's author continues his evolutions: any change in the form layout will be reflected when HTML is generated at next server startup.
(I'm not very familiar with Youtube privacy settings, so please let me know if you can access the video)
Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/
Le 03/02/2017 à 15:56, Stephen Russell a écrit :
Go web based UI and from there you can pick any backend for data you want.
Generating UI for desktop is so limiting for your users last year, this year and the future. Just saying. I am looking at having all my UI have to work across iPad and cell phones. Because it is information that we are presenting. It isn't required to be at a user's desk to suddenly have value.
On Thu, Feb 2, 2017 at 8:54 AM, Paul H. Tarver paul@tpcqpc.com wrote:
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]
thks for the notice
Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/
Le 03/02/2017 à 16:28, Dave Crozier a écrit :
Access OK here in the UK Thierry
Dave
-
Alan Bourke -
AndyHC -
Bob Lee -
Dave Crozier -
Fernando D. Bozzo -
Kurt Wendt -
Paul H. Tarver -
Stephen Russell -
Thierry Nivelet