I have had problems with VFP but never yet had one that I could not
work around fairly easily.
There are several tricks I've learned that have helped me greatly.
(a) BACK UP DATA AND CODE FREQUENTLY! This should go without saying.
It is always helpful to be able to go back to a recent, previous
version of a form, report, or class library - especially if you*
up the one you're currently working on. :)
(b) Encapsulate! Ideally, your application should consist of objects
that are more or less self-contained and which interact with each
other only to the extent that you want them to. Toward this end, you
will want to use variables that are scoped LOCAL, form and class
properties instead of global variables, private data sessions where
appropriate, etc. Give serious consideration to giving your classes
externally available properties and methods, from which you can do
what you need to do with them from outside them.
(c) Learn different ways to do the same thing. This is especially
true when performance or system stability becomes an issue. If you
learn of consistent weaknesses in the product (for example, lockups
when attempting to ORDER BY a field not in the result set), learn ways
of working around them when they occur, and, hopefully, avoiding them
altogether. If an operation that yields a small record set takes a
long time, something is wrong. You can join an almost unlimited
number of tables, of almost unlimited size, with extremely good
performance IF you take care to make sure your query is
Rushmore-optimizable (i.e., every join and filter condition matches an
existing and valid index tag). The only queries that are unavoidably
slow are those that operate on non-indexed fields or those that return
a fairly large result set.
(d) Do things the way VFP is designed to do them. VFP is a relational
database management system. It is designed to work with related
tables, preferably in or close to third normal form, and it excels at
that task. Trying to use it to do things it was not designed for,
such as writing CAD or spreadsheet or COM port management software,
won't give good results. VFP is a great tool, but it is a RDBMS, not
a general purpose programming language. Exceeding, or even
approaching, known design limitations (e.g., using tables that are 253
fields wide) also won't give good results. Often, approaching these
limitations is an indication of poor table design. It is rare for a
properly normalized database to have more than twelve fields in any
single table. You can use SQL selects to join related tables, and
updatable views to modify them, without having to store any single
piece of information more than once.
(e) Document your software carefully. Each piece of your application
(each form, report, class, etc.) should have a brief summary of what
it does, what calls it, what it calls, what inputs it needs (e.g.
tables, class libraries, global variables, etc.); and all code whose
function is not patently obvious should have comments embedded within
that explains what each piece of code does and why.
To the inexperienced this may seem like a waste of time. Just trust
those of us who have had to learn the hard way. The only alternative
is to learn the hard way yourself.
(f) Don't be afraid to seek help. That is, after all, what this forum
is all about. But before seeking help, try your best to solve the
problem yourself. Read the fine, friendly (fictitious?) manual. Try
different approaches. Try breaking a complex problem into its
simpler, component parts, and repeat as necessary until a child could
understand it (unless you are a child, in which case make it simple
enough that your parents can understand it). :) If all else fails,
then try us. We're always glad to help.
Joe
by