Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
System architecture advice
Message
From
05/06/2001 18:57:35
 
 
To
05/06/2001 17:48:21
John White
Micro-Oriented Software Techniques, Inc.
Phoenix, Arizona, United States
General information
Forum:
Visual FoxPro
Category:
Client/server
Miscellaneous
Thread ID:
00515449
Message ID:
00515482
Views:
14
John,

>Was brought into a company which has 350 user VFP 6.0 system with roots back in a 2.6 application. The system has scaled way beyond the exisiting system of 60 users. The FoxPro backend crashes 5 times a day with data corruption. The senior management has decided to go to SQL Server 2000 and has hired me and few consultants with enterprise Database experience. The current programming department (one developer) is extremely resistant to changing the architecture from a client\server(1996 vintage) system to a scalable n-tier or 3-tier system. He is in the process of porting over some of the UI screens to point towards remote views which he will locate on the clients local harddrive. I'm not asking for help with interoffice politics but what resources can I point to convince management that this is still a "hack" and will not work on a system with this many users. We are thinking of a n-tier design with SQL server 2000/VFP BusinessRules COM server/VFP Data Access COM server/User
>Interface. The data will be communicated through the COM layers with either XML or ADO. As some of you know, coming into disassemble someone's kludgeware system can be difficult when the designer of the system is on staff is desperately trying remain relevant yet remain uncooperative.

First, is the cause of the present situation known IN FACT???
For instance, 5 crashes per day must have a root cause. Has this cause been located and confirmed? Most importantly, is it scheduled to be fixed?

Secondly, has the application been gone through to confirm that it is using Rushmore to optimum?

Thirdly, has the database been looked at, from a design *and* usage-frequency perspective, to ensure that only the required data is now being shoved across the wire?... SELECT * was far overused and can be a real source of slowdown. ...Also the indexes need a look-see to confirm match to usage.

Fourth, are there maintenance procedures in place and, if there are, do they take advantage of the fact to reorder the important tables into their physical most-used order?

At the least you might get the in-house guy on your side if you help him with these things and get his participation in the new system. It will be much easier to get a 'new' system in place with the staff guy on board as you really will need his knowledge of things anyway.

Good luck

JimN
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform