Jerry,

I'm going to take occassion of your last reply to start a new thread. This one really interests me and I'm thinking that a separate category would be better, ok?

I'll take your post and kind of restructure your answer and see what you think.

> Interesting that you should lean that way.
> I begin my VFP experience writing the biggest app in the Dept of Revenue, the > gaming app. The hardware requirements, bloat, slowness, and instability of a > DBC with 200+ tables in it caused me to rethink my approach.

> That app is now 21 very much smaller, lighter and faster exes. With no DBC >
> the only thing I lose are views, but there are ways around that which are
> easy to do. Forms are like objects. I don't use the DE but load tables and
> queries in the init of the form. If I change a form that is used in more than
> one exe I only have to recompile those exes to update them. And I generally
> avoid memo fields. Crashing is just a part of the Win OS, but I no longer
> lose table structures, gain corrupted indexes or views when a crash occurs on
> a workstation. Maybe with the commodity workstation that is 1.5 GHz with >
> 512MB of RAM the size of the exe won't matter too much, but that utopia will
> be a while coming in state institutions.

Ok. Lessee..

1. Avoid using DBCs
2. Create smaller, separate Applications.
3. Avoid using Memo Fields.

These seem to be the main points you brought up. About the only one I would question is the avoidance of Memo Fields. I have found them to be as stable as the rest of the DBF structur. Sure, they can get hosed but is it that much of an issue for you?

Here's my preliminary list of use 'off-the-shelf' components I use or plan to use.

1. Use the Stonefield Database product for in-the-field updates & fixes.

2. Use Rick Strahl's Web Connection for all Internet-based communication and data transfer.

3. Use Imecom's (www.imecominc.com) product "Print-2-Image" for all Faxable documents. That is, for converting a report to a .TIF image.

4. Think about using Crystal Reports for all other reports. They provide drill-downs and these can be used on a web site. (This is the only one I don't currently use but expect to soon.)

5. Use a solid framework. I currently use Visual MaxFrame Professional but I think the others are all equally good choices.

6. Use the West Wind Help Builder.

In the 'roll-your-own' category I'd do the following:

1. Create a series of classes to manage and control my application - unless I can find one already available. I'm thinking along the lines of a distribution, maintenance and upgrade object that handles just that for EXEs, Data and other issues.

This is the 'big one' for me right now. I need to be able to manage literally thousands of users, each with a different state & county data set, sometimes multiple. Each data set can be up to several CD's worth of data. That's why we want to use VFP on the desktop - the premier ISAM data file manager - period. Hpwever, once the initial data set has been installed updates are relatively trivial. These can be done over the Internet easily, say in a nightly maintenance mode kind of approach. I already have developed a method for updating individual field values which saves me the hassle of sending a whole record if only one field changes. Web Connection is ideal for handling this and can also scale - a big issue as well, should we grow as we'd like.

This 'auto update' process will also work for each and every program as well. The way I figure, if I can make a system that can essentially keep itself updated all I need to do is create a new app, test it thoroughly, and then place a 'tick' in a backend table and when the folks connect they will then know of any changes automatically and I can then let them updaye immediately or auto-schedule an update for late at night.

Actually, it should work for just about anything - given a thoughtful enough design.

2. Create a Project Manager <---> Visual SourceSafe object.

3. Complete the FAX Manager object I've started. <g>

4. Complete an Email Manager Onject.

5. Create a Manager Manager. This one is a 'biggie' IMO as well. This way, all I need to do to add a new Manager to my process is add a record in a table and provide the requisite files. Again, small pieces that know how to load themselves.


Anyway, perhaps this will spark a few brain explosions. <g>