my company using foxpro for dos until now, as I want to investigate is there any potential to change to client /server infastructure (as there are four branch outside using vpn approach to retrieve the file server at the main office), if still using foxpro for dos 2.6, can be change to c/s approach?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
can different foxpro share database?
- Thread starter konnic
- Start date
Konnic,
My advise to you in this case would be to move to VFP. If you are going to switch languages anyway, this will make your life easier. VFP has great native support for it's database as a "Backend", and if you outgrow it, it is not *too* bad a transition to move it to MS SQL server.
Best Regards,
Scott
Please let me know if this has helped![[hammer]](/data/assets/smilies/hammer.gif "[hammer] [hammer]")
My advise to you in this case would be to move to VFP. If you are going to switch languages anyway, this will make your life easier. VFP has great native support for it's database as a "Backend", and if you outgrow it, it is not *too* bad a transition to move it to MS SQL server.
Best Regards,
Scott
Please let me know if this has helped
The answer to your first question is Yes, Foxpro can support a Client/Server application.
And, like Scott recommends above, now is the time to change your language from the original DOS version Foxpro. Whether you make the bigger step up to Visual Foxpro or a more modest step to Foxpro for Windows (yes, it too is a "dinosaur", but it is much better than DOS), get away from the DOS program as soon as you can.
However, the other bigger question to ask is how well will your application perform over your VPN.
Most remote users are still using modems to access their VPN. Even VPN's which utilize the Net for an IP connection, typically have users with modems required to get onto the Net. The speed (or lack thereof) of the modem
connection will be the "weakest link" in the application performance at the user's end. Keep that in mind with any approach you might want to take.
If all of your users are lucky enough to have a high speed connection to your VPN, then they might accept the application's performance. But modem users might not appreciate any slow response.
There are a number of approaches to handling remote user's access to your system's data and you might want to review a variety of them prior to making your final choice.
Good Luck,
jrbbldr
jrbbldr@yahoo.com
And, like Scott recommends above, now is the time to change your language from the original DOS version Foxpro. Whether you make the bigger step up to Visual Foxpro or a more modest step to Foxpro for Windows (yes, it too is a "dinosaur", but it is much better than DOS), get away from the DOS program as soon as you can.
However, the other bigger question to ask is how well will your application perform over your VPN.
Most remote users are still using modems to access their VPN. Even VPN's which utilize the Net for an IP connection, typically have users with modems required to get onto the Net. The speed (or lack thereof) of the modem
connection will be the "weakest link" in the application performance at the user's end. Keep that in mind with any approach you might want to take.
If all of your users are lucky enough to have a high speed connection to your VPN, then they might accept the application's performance. But modem users might not appreciate any slow response.
There are a number of approaches to handling remote user's access to your system's data and you might want to review a variety of them prior to making your final choice.
Good Luck,
jrbbldr
jrbbldr@yahoo.com
You could look at Foxpro for Unix
running under linux, you could then
centralise everything with telnet sessions
into the main server, would require a few changes
to your FPD App,
We have had a play with it here, actually runs
faster under linux/(sco emulation) than fpd
(same hardware) kinda shocked me.
we have a custom written point of sale system
written in FPD, running at 40 sites, (250 mill turnover)
we had looked at FPU for some of the slower sites
(i.e. 386sx25 with 4 megs), didn't in the finish
Anyway we converted our POS system to FPU, just for
a play to see if it would work, only problems were
going from 25 line mode to 50 line mode, and printing,
firing cash draws,etc etc, few colour issues all minor
Anyway is just an idea, there is some link to a FPU site
in here, (has a little stub program to run your "app" under linux, i.e. no need to track down FPU)
Anyway I hope this helps
Zim
running under linux, you could then
centralise everything with telnet sessions
into the main server, would require a few changes
to your FPD App,
We have had a play with it here, actually runs
faster under linux/(sco emulation) than fpd
(same hardware) kinda shocked me.
we have a custom written point of sale system
written in FPD, running at 40 sites, (250 mill turnover)
we had looked at FPU for some of the slower sites
(i.e. 386sx25 with 4 megs), didn't in the finish
Anyway we converted our POS system to FPU, just for
a play to see if it would work, only problems were
going from 25 line mode to 50 line mode, and printing,
firing cash draws,etc etc, few colour issues all minor
Anyway is just an idea, there is some link to a FPU site
in here, (has a little stub program to run your "app" under linux, i.e. no need to track down FPU)
Anyway I hope this helps
Zim
- Status