Looking for Advice

[rkolva]

Trying to decide on the best way to change a stand alone, single user app to a multi user app and thought I would ask the experts. I've inherited the app and while it has worked well over the past 6 year and has some nice features a lot of the code is sloppy, difficult to read, and the original developer just makes too many assumptions about the state of the environment.

Here are some details about the current system.
* The app was originally developed 6 years ago as a stand alone data entry system. We've since added the ability to get and recieve XML data via HTTP
* All the free tables, no database container, are opened as EXCLUSIVE
* All the business logic is tied into sublcassed VFP controls
* Validation is done via a data dictionary that defines ranges, skip patterns, messages, accessability, question labels, field names, data types, etc. This data dictionary is also used to validate the data at the server/CGI end. there is another app that non-programmers use to populate the dictionary and this is
* The final app is generated from the contents of the dictionary, forms are dynamically created by a build program. We may have 20 - 50 of these data collection apps in use at any one time and the ability to generate a complete app from the dictionary in a short amount of time is a requirement.

It's really the lack of shared data access that is prompting the redesign.

The system should have the following characteristics
* Be able to run as a local app offline
* Be able to support several users on a local network
* Get and Post data via Http when online

My first idea was to use a VFP database container and views and that still may be the way to go. I've also seen Craig Berntson's and Rick Strahl's articles on COM+ and MTS. I don't think we'll ever exceed VFP's capabilities but I am a little concerned about VFP's future in a 64 bit future.

Any advice will be greatly appreciated.

Ralph Kolva

 

[KenWMurphy]

I don't think you need worry about the future of VFP - there have been predictions if the demise of VFP for as long as I can remember. I still use VFP.

If you are really looking at re-creating this as a multi-user app, you are probably looking at a fair amount of work. This being the case, do a complete re-definition. The result of that definition may lead you to the answer that you need.

One option you might take is to leave this app as a standalone "data entry" app. Each user would have his/her own set of tables, etc. but then add a database update function. The users would not actually see any difference - they would continue to use the same windows that they are used to using. When they click the "save" button, you could have the app save that record locally and then to a server based CDX or even to a SQL database. The primary advantage of this type of solution is that you do not have to introduce change to the user.

Ken

 

[rkolva]

Thanks Ken,

I guess the way I've been looking at this thing is almost a complete redesign using all of the original requirements with the addition of being multi user and Internet aware. That's where my question comes in, if I'm going to do this what would be the best approach? We have other VFP programmers and simplicity certainly is attractive in sharing the maintenance of this app. But I also don't want to put the organization in this same position in another 6 years because the approach I took didn't allow enough flexibility in the near future.

If I understand your suggestion correctly this is sort of the approach we take already. As the app saves the record locally it's also transmitted to our server's DB2 database and if we need to redistribute data the app downloads and writes that data to its own tables, but this doesn't happen real time. The problem we're having is that some versions have more data than 1 person can key into their exclusive tables in an adequate time period. So we need to have shared access so the data can get into the system in a more timely fashion. I guessing that this also means that I have to address locking schemes and data collisions also. I think this is why the original developer used exclusive access to the tables, he didn't want to deal with it.

I suppose I could use your suggestion with a complete refresh of the user's tables but I think that might slow things down a bit.

Thanks again,

Ralph Kolva

 

[alvechurchdata]

To take Ken's suggestion a stage further - you could base the existing data-entry forms on views. Each user would have their own dbc locally which would hold their view definitions.

I am a little concerned about VFP's future in a 64 bit future.

We've got support from Microsoft until 2014 and a lot can change in 9 years. If I look back 9 years to 1996, VFP had just been launched but Visual Basic 3 was the language to use because "Microsoft will drop FoxPro". Fox is a stable, long-term language.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[TamarGranor]

It seems to me that the way you ensure data flexibility is by not tying forms to data directly. Either use one of the frameworks or build your own, but work with a set of objects that separates the data from the presentation of that data. Then, if the time comes that you need to change to a server back-end, the changes are limited to that one set of classes that talk to the data.

Of course, if you go this way, you also need to set up your forms with a client-server mindset--things like only getting the data you need now, not just opening a huge table.

Tamar

 

[Nro]

Hi

In all my systems, I'm using the same approach. Each time the user log in the application, I create a temporary Database container, where I then create all the local (or remote) views for the application.

All the table are part of DBC, but the opening of each, is by creating an object. I can open a Fox table, SQL Server or Access table, with little change of code.

If I have to create a data entry form, I usually have two table/view opened : one navigation table (or view), and one local (or remote) view for data input, containing only one record.

For example, I have one Customer table where I skip, locate, move the pointer. Each time the record number change, I REQUERY() the view containing the one record (the one viewed by the user). The advantage of this approach is that I can do whatever I want with this record : rLocking, TableUpdate or tableRevert for the data entry. I can even wrap this with BEGIN TRANSACTION and END TRANSACTION.

Maybe it’s not a very original way to manipulate data, but it works very well for our systems. In all the forms, I attach a custom object with all the logics of IO mention up, then is possible to compile this custom class OLE Server and use it with VB .NET (or other language using COM)

I hope it gives you some ideas.

Nro

 

[rkolva]

Thanks Tamar and Nro,

I've been thinking about this most of the weekend and it seems like the best aproach for me is what you're both suggesting. It may be a fair bit of work but it seems the correct approach that will allow for a good deal of flexibiity in the future.

Thanks for all your advice,

Ralph Kolva