>Ok, I've been playing with VFP (3.0) for awhile, reading everything I can get my hands on and trying to understand how VFP thinks. Now I have two questions on approaching VFP and forms etc.

First, unless you're supporting Windows 3.1, I'd recommend upgrading to 5.0 as fast as possible. VFP 3.0 is a little buggier than one would like.

>1) As suggested in all of my literature, I've created a database out of normalized tables, breaking things down into individual parts to avoid redundancy etc. Thus when I need to create my forms (my project is very forms/data entry based) I need to put different parts together via relations to make the interface understandable to my users. I haven't been able to do this easily with standard form controls and most of my documentation uses forms that have relatively simple data environments with a single or two tables per form.
>
>It was suggested here that I use Views to create some of my one to many, and many to many relations which I could then use as bases for my forms. However since I can't create indexes on Views, I'm assuming I'd have to create a "complex" View that contains every possible field I'd need in a form since I can't relate my Views to my other tables in the proper Parent to child relations.
>
>My question is what is the best approach to forms which need to display related info (fields) from multiple (3+) tables? Do I forego normalization and create redundant tables? Keep fighting Views? Argh.

You are much better off staying normalized - doing otherwise will cause hair loss due to tearing :)

Can you give us some sense of the resulting data structure? I find myself assuming there's one driving parent table, in which case it's at worst a long SELECT,

>2) I have a number of different "code" tables in my DBC, one for each type of code (there are about 20 tables). I have read where others have included all codes in one large table and included a "codetype" field to differentiate between code types. I was afraid this would slow down my app, which is a typically a better approach?
>

I'd prefer the several small tables approach; if you're doing a lookup for more than one kind of value, you're going to need multiple file handles/record pointers anyway, and I think it's a more compact approach, too.