Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="Andre" data-source="post: 3542987" data-attributes="member: 25930">I agree with MR, though I strongly recommend using an ID field as your primary key, instead of the customer's name. Why? Two people/companies can have the same name. You also don't have to remember if you keyed in the company as "The RPG Source" vs. "RPG Source".That said, I would also strongly recommend some kind of customer lookup form. When using an arbitrary ID for customers, it's quite easy to enter the same customer more than once. Before creating a new customer, always pop up your customer search form and look for data that matches - name, address, phone, etc. - before creating the new record.As for ensuring that you only display appropriate records, the simplest method is to base the form on a query, which is set up to only pull the records you want, for instance only customers with an active lease. A more flexible way is to create various filters on the form, so you can sort for "Active", "Inactive", "Past Due", or whatever other criteria you might be using. You can tie the filters to command buttons, if you don't have too many. Or you can create another form that has all the fields you want, then uses code to filter your main form when you click a command button.I admit I'm fairly sloppy when designing db's. I start with what information I want out of the db, then work backwards to determine what fields I need, then group the fields into tables. Once I've created the table relationships (one of the most important steps), I then throw together some quick and dirty tables, forms, and data to test it. Once I've found the most obvious problems with my design, THEN I sit down and work up the real db. Not the best way, but for smaller db's, I find it works for me.</blockquote>

Verification