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:[email protected]] On Behalf Of Paul H. 
Tarver
Sent: Thursday, February 02, 2017 9:54 AM
To: [email protected]
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]

_______________________________________________
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/80838f1ca795b14ea1af48659f35166f18fd5...@drexch02.corp.globetax.com
** 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.

Reply via email to