>2. I've heard this argument a lot, but 'wasted' keys are a great barometer of how the app is being used. The fewer the better. If there are a lot of 'wasted' keys that means either the app is difficult to use or the users are wasting a lot of time entering things before they are ready. In either case, it's time for a rewrite or training.

I agree, the complaint is minor, and if the problem is prevalent, then something is wrong with procedure. But it just doesn't seem like the right way to do it, especially if there are a lot of users, and the system will be around for awhile.

>I'm with Dave on this one, use a stored procedure for appending records.
>
>And no, IMHO, you wouldn't use a seperate form for INSERT-SQL, you'd remove your controlsource references and put code in your refresh to manually stuff values into the proper controls, or you could use memory variables and a scatter in the refresh (less coding, but I've grown to hate memory variables). You'd also need to add similar code to your save function.

This seems like a LOT of code to do. Is this really the 'preferred' way to tackle the task? Would not each of my forms need specific code to manually 'stuff' values, and manually map the fields to their control.values or memory variables? I have about 20 major data entry/ viewing screens, each with corresponding tables. Some of these screens Have as many as 35 fields to enter when adding a record. You can see why the thought of straying from databound controls makes me cringe. How does Codebook or Maxframe approach the issue? Append blank, or INSERT SQL?
BTW, as a junior professional programmer, this is my first VFP app, and all of everybody's help/insight to my problems has been invaluable. Thanks for your reply, Matt.

Erik Moore