>>I have this client who's thinking about rewriting a system in Fox 5 or 6. The system is currently in Access. Now I would love to see this happen becuase I am much more comfortable in Fox. But I'm not sure what reasons I can give them to give them that final little boost to make them convert. Can y'all help me out with some reasons? Thanks.
Hey,
where is my text gone?
Look at
http://ourworld.compuserve.com/homepages/tdoc/jjorep.htmfor a report cmparing developer languages
Some text:
MS Access is positioned by Microsoft as an easy to use end-user development product with superb support for point and click form and query design. In addition it comes complete with a fully featured development language of its own which is in essence a dialect of MS visual Basic.
While the product is, on the surface, very easy to use and provides superb reporting features it is not in itself capable of producing stand-alone applications. The system requires a full copy of MS Access in order to be able to run the deployed application, there is however a developers kit available for purchase that provides a crippled copy of the Access run-time engine which can be distributed free of licence fees.
At this point in its history MS Access suffers from the following two major problems.
From the very first version it has proved extremely demanding on hardware resources: version 1 and version 2 were next to unusable on anything less than a 486x33 PC with 8MB of RAM (Microsoft recommended a minimum of a 386 with 6MB of RAM but this was always unrealistic). The RAM requirements increased sharply as the size and complexity of the database and or application increased.
This situation has worsened with the release of the 32bit version 7 for Windows 95. Indeed the release of Microsoft Office Professional for Windows 95 went ahead without MS Access 7 in the box. Instead a voucher for MS Access 7 and a copy of MS Access 2 were included in the box. On the eventual release of version 7 Microsoft had to retract its claims that the system would run in 8MB of RAM and offered a refund of part of the cost of Office Professional to those who had the voucher for MS Access 7. The end result is that minimum realistic requirements for MS Access 7 are now set by Microsoft at 486x66 with 12 MB of RAM. Developers are reporting that for deployment of workable applications a system with a minimum of 24MB of RAM and a P100 Pentium is a more realistic option.
The second problem is more subtle. The ease of use of Access is such that it encourages less skilled developers to tackle large and complex development projects for which the system is not really designed (hardware will catch up eventually in the same way that hardware improvements have so improved the performance of all XBase based applications). This leads to the development of promising early prototypes using small amounts of data which do not reveal the problems that will be experienced when the application is scaled up to production sizes. Indeed developers have reported serious performance problems with even small systems with less than 5,000 records.
The principle problems relate to data manipulation in other words the speed at which new records can be appended, deleted and updated. For even small to medium sized databases the append time stretches considerably as the number of records increases, this makes it a very poor choice for transaction intensive or on-line applications such as customer order enquiry systems.
We have a simple example of this problem. For a simple one field update and append of a single unrelated table in a program loop running from 1 to 100000 (inserting 100000 records). The insert took 15 minutes on a P166 Pentium class processor with 48MB of RAM using Access version 2.0. A similar test using the CA-Clipper XBase system required approximately 1 minute 45 seconds and the same test using FoxPro took 3 minutes.
The combination of heavy resource requirements and poor data manipulation result in very poor scalability of MS Access applications. As such it should be accepted at this stage in its development, that MS Access is really only suitable for small workgroup applications which are not mission critical, do not involve large transaction volumes or large quantities of data.
It would however be fair to say that MS Access is suitable for the feasibility study phase of a development project, it is a useful tool for the creation of prototype applications, Indeed MS Access is particularly appropriate for the development of Client server Prototypes as its support for SQL is very comprehensive. However one should always remember that the prototype should never go on to form the core of the production application.
