Ted:

It's a pleasure to have you join in on this conversation as your name is one

that I have always associated with quality information when it comes to VFP.

As a matter of fact, in the course of opening this line of discussion here

on ProFoxTech, I did some digging and I found that at some point I purchased

a book entitled 'MySQL Client-Server Applications with Visual FoxPro"

written by Whil Hentzen and edited by some guy named Ted Roche! :)

Since I started this thread, I've read about 12 of the 22 Chapters and I'm

learning some of the answers to some of the questions I have and the

examples are giving me some idea of how to proceed.

Based on my reading so far, I'm of an opinion that the fastest way to get

this project off the ground (which I've already begun) short of using a

framework is to use a combination of SQL Pass-Through and Remote views. My

idea would work something like this:

1) User gets a search screen to find the member they want to edit (this is

very similar to the current dos experience)

2) Search screen uses SQL Pass-through to query back-end and return results

of query to grid for user selection

3) User double clicks on member and opens an edit screen that uses a Remote

View to handle SQL Update for a single record. (Same screen could be used to

add new user)

4) User closing edit screen triggers confirmation to save or discard

changes.

In my case, I feel that most of the data entry required will work perfectly

fine using this methodology and will not incur additional keystrokes for the

user. All the custom reports will be created using SQL Pass-Through.

My next area of interest is whether I can create the Remote Views

programmatically because I'm currently using DSN-Less connection strings to

connect and query the database and I would prefer not to have to create a

DSN just for the remote views.

Any thoughts about this plan of action?

Thanks!

Paul H. Tarver

Tarver Program Consultants, Inc.

Tel: 601-483-4404

Email: paul@tpcqpc.com

-----Original Message-----

From: Ted Roche [mailto:tedroche@gmail.com]

Sent: Monday, February 06, 2017 2:48 PM

To: profoxtech@leafe.com

Subject: Re: SQL Backend Question - Part Deux

Paul:

The issue with moving from a VFP record-centric view of data to a

cursor-centric view as is used in most client-server software is that there

are a LOT of gotchas with getting VFP to work that way, and a lot of design

decisions you need to make: do you use cursoradaptors, remote views, SQL

Passthrough? All three are valid and work, but each has different

limitations and issues you need to look out for. Do you use local cursors

tied to the remote data? Or do you build your own data objects? Will you be

switching backends, say from SQL Express to MariaDB? Then you need to think

about a Data Manager and some translations. Do you buffer the local cursors?

Do you buffer the remote data? How to you handle rollbacks? What's your

strategy on data

conflicts: last save wins, rollback and force a retry, or give the user edit

controls of then-now-edited data?

>From experience, you can spend several years working through all of

these questions, and building a robust underpinning to your application

logic, and then find you need to alter your strategies as you see how your

software is being used.

Or, you can build your application using a framework someone else has

already built. They have an opinion about which tools, commands and

strategies to use, and you can build your app on top of their framework as

you learn the details of how it works and perhaps why the decision decisions

were made. You can ship an app in weeks or months vs. years and continue to

enhance it rather than reinventing the wheel. Back in the day (oh, boy, here

goes the geezer tales), I installed Visual Maxframe, read the documentation,

and shipped the initial app in two weeks.

I have worked with most of the major frameworks: Mere Mortals, Visual

MaxFrame, Codebook, West-Wiind, Visual Extend. Sadly, I haven't worked with

FoxExpress, which I also hear great things about and whose authors I count

as friends. IME, any framework will get you up and running much faster than

building it yourself.

If you want to look at real code that people use in real production

environments and have tested in real-life conditions, then check out the

commercial frameworks. (I haven't shopped in a decade, so perhaps others can

say which are still being maintained)

There are also free ones. I know Codebook is available on this very forum

(https://leafe.com/dls/cb) and there may be others available.

On Mon, Feb 6, 2017 at 3:14 PM, Paul H. Tarver <paul@tpcqpc.com> wrote:

> This is true, but the application was developed in MagicPC and my

> version of that product only works with Btrieve v5 and will not work

> correctly with later versions. We are able to function by using WinXP

> in a virtual machine and quite frankly if that quits working, I can

> make it run in a DOS Virtual machine if necessary.

>

> Thanks!

>

> Paul H. Tarver

> Tarver Program Consultants, Inc.

> Tel: 601-483-4404

> Email: paul@tpcqpc.com

>

>

> -----Original Message-----

> From: AndyHC [mailto:andy@hawthorncottage.com]

> Sent: Sunday, February 05, 2017 5:02 AM

> To: profoxtech@leafe.com

> Subject: Re: SQL Backend Question - Part Deux

>

> According to Wikipedia the latest offering from Btrieve is backwards

> compatible and runs on Win10

> https://en.wikipedia.org/wiki/Btrieve#Pervasive_PSQL_v9

>

[excessive quoting removed by server]

_______________________________________________

Post Messages to: ProFox@leafe.com

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/04c101d2818f$5c1f3060$145d9120$@tpcqpc.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.