I have a very large Client Server B

[topgunf25]

I have a very large Client Server Billing Application written in Visual Foxpro 6.0. The only thing the server does is act as a file server.

Does anyone have experience with a large number of clients i.e. more than 150 clients. I have a so called expert that is telling my customers that you should not use Visual Foxpro with more than 40 users?

My monitors show very low usage on the server.

Help!! losing customers

 

[chpicker]

Well, unfortunately, I can't say I have any experience with lots of clients (max so far has been 10)...but if your server is only being used as a file server, I can't imagine why the number of users has anything to do with whether or not to use FoxPro. As far as I know, as long as the file server is robust enough to handle the load, you shouldn't have any problem. You'll just need to be very careful of data integrity with that many people accessing your tables at once. Make sure your record locking, buffering, etc. is as optimized as possible!

 

[dgrewe]

Well your so call expert is full of S***, I have a client running Foxpro with over 500+ users and the speed is very good.

I also have a foxpro driven web site with over 500+ customers access it and the speed is very noticeable faster then the competitors.

Where is the exe being call from the file server or the load hard driver. If you start the exe from the file server there is your killer.

Also look at you config.fpw and foxuser files. make sure all work is being done on the clients local hard drive. David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[topgunf25]

Thanks for the input. All the Fox files and exec's are being executed from the workstation. My position is you are right Foxpro only see a one on one with each workstation. Windows NT/2000 has the responsibility of keeping the files accessable. All my test have shown I can have thousands of user with a problem to the application. I use file locking at the highest level of my tables i.e. relational/higher archial kind of. I has been working very well for more than 7 years, but only have experience with about 50 simultaneous users.

The only data integrity is due to power problems, etc. I am using the old routine some provided years ago to do a low level read on the header and reconstruct the file.

I running Client Server Mode, but also have just implemented a Thin Client Mode/Client Server using the Windows 2000 Terminal Services. The Terminal Services is simular to Citrx. You only need to designate a server or the same server to be a Terminal Services server.

Thanks for the input, keep it coming.

 

[fluteplr]

BTW, You are not running in client server mode. You are running in file server mode, the server just serves up files. To be running client server, requires a database such as Sql Server or Oracle on the server that actually can do some work.

 

[topgunf25]

Actually I can configure the application by workstation to run several ways.
1-Application on the workstation/Database files on server.
2-Thin client with Terminal Services connected to a terminal server, connected via 100/MBit LAN to File Server.
3-Database Application running on server with files and taking SQL or program requests for reports while workstation waits for completed q'd result file. The database server so to speak can be a single task or a multiple task on the same server or many servers sharing the request q's. The thin client configuration and the Database Application Agent are used for low bandwidth clients.

 

[dgrewe]

Excert of an email response to TopGunF25
Sure, I'll explain how I have the 500 user application Set up.

1. All workstations have foxpro or the runtime modules install on the local hard drive. (MIS troops have VFP installed, All users have the Runtime modules.)

2. All Applications are compact exe's so the VFP libraries and runtime are not built into the EXE. Makes it smaller for faster file transfer.

3. All application.exe files sit on the server, but are copied to the workstation hard drive and started there. To do this I use a loader program, it copies the application from the server to the local hard drive and then starts it. The application starts by calling a renamed config.fpw file that called the loader.

http://ibs.internationalbid.net/home/dave/code_html/bidsys.html

http://ibs.internationalbid.net/home/dave/code_html/loader.html

4. The Windows Desktop Icon parameters are:
(MIS troop example of Icon)
Target: "C:\Program Files\Microsoft Visual Studio\Vfp98\VFP6.EXE" -t -cF:\bidsys\bidsys.cfg
Start in: "f:\bidsys"

5. All file locations are stored in a database BIDSYS.DBF. At program startup the database is opened , the fields are placed in memvars, and all files are called using the memvars.
set code example below.

http://ibs.internationalbid.net/home/dave/code_html/setfcmem.html

6. Each workstation does not do any work on a Server Hard drive. I have a copy of a FoxUser.dbf and FPT in the server main application directory but renamed to bidsyscf. I have the bidsyscf set to the way I want it. The main application copies the bidsyscf to the local hard drive and then sets the resource to that copy. As you may have noticed above, I have a FoxPro Config.fpw commands built into the loader file.
....
do SetFcmem && declares all F* Memory Variables
on error **
if !file(fcTempDir+"BIDSYSCF.FPT&quot
use (fcSysDir+"BIDSYSCF.DBF&quot
copy to (fcTempDir+"BIDSYSCF.DBF&quot
endif
set resource to (fcTempDir+"BIDSYSCF.DBF&quot
...

7. All temp files, Views, Text Files, Queries, etc are done on the local hard drive.
example
use (fcSysDbf + " CUSTPROJ&quot
select * from CUSTPROJ;
where CUSTPROJ.QUE_DATE = ldDate;
into table (fcTempDir + "CUSTPROJ.DBF&quot
or
create view (fcTempDir +"CUSTPROJ.VUE&quot
etc

8. In short, the file server just sits there with the files open. It does not do any work at all. No files are created on it, I even have the directory rights for file create turned off for users, Only MIS personnel have file creation rights on the server. All file create actions are performed on the local hard drive.

9. Ok here comes the start of the Old School. I have done tests on applications were all files are closed and only opened when needed and on systems where all files are opened at the beginning of the application and left open until the applications ends. I have found that if you only open dbf's as you need then, the system runs faster when the dbf's are on a local hard drive. It runs faster if all dbf's are opened at the start of the program when the dbf's on are on a server. I have formed a comprise. When the user is sitting at the Application Main Menu (not a sub menu) , all DBF's are closed except for the ones needed by the main menu for security/authorization reasons. Any program called from the main menu has Close Data as the first or second command line. Any files needed by the application are opened in the app and left open until the return to the final menu is made.

I Hope This Helps You David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[topgunf25]

Thanks Dave that helps.

Funny, without talking to you, I have done a similar design, but I have the temp files on the workstation and the main tables on the server using record locking when necessary to control updating to one user at a time.

A copy of the program sits on the workstation, and I too have a loader that checks the date and time of a zipped copy of the main myprog.app on the server. If they are not in sync I download the main program explode it and execute.

I assume your application is the one on your web-site?

Thanks for the info.

 

[dgrewe]

No the application I explained above is not the Web Based one. If you want to see the Web based one,

http://www.internationalbid.com

and select "Guest Printer" follow instructions. Some features of the site are disabled for a guest user. Everything after Login is foxpro generated. Clue, I did not say run, I said Generated. David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[topgunf25]

Look nice thanks.