Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I feel your pain ... working with Access gets so difficult where there are complex requirements.</p> <ol> <li><p><strong>Gather and document the requirements</strong></p> <p>Make sure you've teased out every possible wrinkle and contingency from the client, and put it into a flow chart or something.</p></li> <li><p><strong>Extract the models</strong></p> <p>Figure out what models are being used -- customers, addresses, vendors, products, etc. These will have to be created as tables or adapted to existing ones. </p></li> <li><p><strong>Extract other variables</strong></p> <p>What could potentially change over time and/or what will the client want to be able to change via an admin screen? You'll have to decide which of these variables to put into tables, and which are ok in the code (form logic and/or VBA).</p></li> <li><p><strong>Design the tables for the wizard views</strong></p> <p>I imagine you'll want a <em>wizard screens</em> table, where each row corresponds to a step; each should have (other than an <em>id</em> column) a <em>previous screen</em> column, and a <em>form name</em> or <em>form template name</em> column. You'll need a second table <em>choices</em> with a many-to-one foreign key linking back to <em>screens</em>; each row here will correspond to a possible outcome of the view, and the target next step in the wizard.</p></li> <li><p><strong>Design the forms</strong></p> <p>Finally, design the forms corresponding to each wizard step or template, pulling data from the structures in 1-4 as needed.</p></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload