Stuart McLachlan
stuart at lexacorp.com.pg
Thu Mar 6 17:56:00 CST 2003
> On the assumption that both forms are almost identical, you're quite right. > However, my shifting opinion derives from a realization that viewing and > editing forms are often quite different, and insert forms different again. > The use of a single form often requires the loading of combo boxes, list > boxes etc., some of which lists may be quite large. OTOH, a query could use > joins etc. to resolve all the FKs without populating any lists. You would > see read-only controls that display the columns of interest without > incurring any control-population overhead. Then when the user clicks the > Edit button, you populate the lists (taking into account various business > rules such as "you cannot change the customer on an existing order"... > leading to a significant increase in performance. > As I wrote originally, I'm still shifting. My current feelings are expressed > above. In a few recent experiments, I found a) much better performance; b) > better encapsulation of the logic (i.e. if it's a edit-customer issue, it's > obviously in the code behind frmCustomerEdit). I use both approaches depending on circumstances but seem to be using separate data entry screens more and more recently. A prime example of using two different forms is where use a combo boxes during data entry that need to restrict the available options. The combos needs to show only active records, items in stock etc. When you review previous entries, you need to see the details whether the item is currently in stock or not. I've also recently found myself using separate unbound forms for straight data entry in a few circumstances (after being an unmitigated bounder for the last 10 years <vbg>) -- Lexacorp Ltd http://www.lexacorp.com.pg Information Technology Consultancy, Software Development,System Support.