> > Today I use VFP to improve my own productivity and distribute my work to a very small community.
> >
> > Foxite is a great resource for keeping me out of trouble, but someday I know I'll need to hire an expert to make my applications more robust and networkable.
> >
> > So I direct my query to you VFP consultants in Foxite land: What are the common coding practices that newbies make that I should avoid to make your consulting life easier?
> >
> > Three things I've heard on Foxite so far
> >
> > 1. Keep public variables to a minimum
> > 2. Use Hungarian notation
> > 3. Create your own subclasses of the VFP base classes
> > 4. . .
> > 5. . .
> >
> > Are there certain coding practices that make you want to tear your hair out?
> >
> > Dan Baker
> > Effort of the Poconos, PA, USA
>
>
> Question
>
> I am working on a boat sale closing form
> that will print all of the many forms that the
> different state agencies and bank require.
> I am at the early stage so I can change anything at this point
> Right now I have one file that contains all of the information needed
> Customer info, lien holder info, boat info color length, propulsion etc,
> Is there a compelling reason to break this into several files? Lien holder file, customer file, boat file, etc The table will never be huge maybe over many years it will Have thousands of records not millions not even hundreds of thousands

Professional software developers are supposed to know to normalize data files. This should be a new topic.

The sale is one file. The customer is another file. The boat may have been sold with extras. These could be in yet another file. The boat base price plus the sum of the extras is the final sales price on the invoice. Very typical stuff.

If you have all data in one record, multiple people cannot work with the record at the same time.

Mike Yearwood