Designing a VFP Multi-User Application (or "Gosh, I need help!")

[MorgyDogy]

Dear Members:
I have started on a re-write for a client that has a FoxPro 2.5 program. It has Inventory/PO/Customer/Supplier/SO functions. All screens and reports are self coded - meaning none of the 2.x screen writer or report writer, etc.

Now, to redo something like this with VFP 6 is in itself troublesome. In addition to that, I must now upgrade to a Multi-User system. This is also a Win XP PTP network without SQL server, etc.

Since I have not yet created anything in VFP for more than 1 user, I poured through the Microsoft and some 3rd party documentation on multi-user considerations.

I know all about sharing, buffering, transactions, etc. yet I don't have the "glue" to put it all together.

Do I create a "TSR" like program on a server that handles all the "Client" requests?
Do I just load copies of the same app onto all workstations and have each workstation access the Databases/DBFs from one (unused)PC? If so how do I treat these databases? Can I just keep the DBC and DBF and MEMO files on that system and still have all the buffering and trans. done from the clients?

I am nervous, confused, and getting a bit stressed out - is this normal? ;-)

 

[Mike Gagnon]

You have a choice.

Either you make a server/server application, where that application and the tables are on the server and everyone accesses the same executable. That has it's inconveniences where in order to update the application every body has to be out of it.

Or a client/server application where the data sits on a server and everyone has an exe. This is easier to develop but in order to "upgrade" every one you have to copy the exe on each station.

Normally I use server/server type, but I configure my own computer to "imitate" the server, fdisk a partition and put everything as if that extra partition was the server. Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[AllanB1]

If you haven't already visited it, it would be worth your effort to refer to the following MSDN article on the subject, authored by Doug Hennig:

http://msdn.microsoft.com/archive/en-us/dnarfoxgen/html/msdn_buffer.asp?frame=true

Al

 

[MorgyDogy]

First mgagnon:
Thank you for your response.

I think the server/server solution is to abstract and Foxpro 2.x based. A company I worked for had such a solution. I don't think that using VFP in such a manner as they were using - without user tracking, and robust record locking - is an option these days.

Can you be more specific as to how you do this?

 

[MorgyDogy]

AllanB1:

Thanks for the link.
I have covered this topic numerous times, yet I feel I am still lacking a step-by-step on actual implementation within a working app.

 

[wgcs]

I would refine Mike's descriptions a bit more:

What he calls "server/server" could be described as "File-Sharing Access with shared Executable"

What he calls "client/server" would be more accuratele called "File-Sharing Access with Client (or Distributed) Executables"

Another approach, would be true "Client/Server", where one machine sits running a "TSR" program (service) as a server, and all clients are running a different, client, executable, which knows how to connect to the Service on the Server computer.
VFP isn't designed to be the Server in this circumstance (though I've been fiddling with making it so...); MS really wants you to use SQL Server, and has provided "SQL Server-Lite" in the form of the Free MSDE server, which can be used in the same way.

----
The real determining factor for how to go multi user are your specific circumstances:
1) How many locations will it be installed at? Will there be someone there as a DBA (data base adminstrator)?
2) How many users will be accessing the application at once?
3) How many transactions will hit the database per second?
4) How important is data corruption? (VFP tables are more susceptible to corruption than most Client/Server databases)
5) How frequently do you expect to update the application? Updating distributed EXE's can be a nuisance (though build it in from the beginning and you can get it to happen automagically) as can be updating a single, shared EXE.

For example,
If everyone using the app are going to be about 5 people in one room, and you'll be an on-site support person, then you can simply say "Hey everybody, exit the program so I can update it".... but if you are going to have 100 people using it in 20 different offices, then you'd need some managed way to auto-log-off all the users for an update.