I've normalized my database, I've built relationship with the different tables, I'm trying to figure out my next step.

I haven't populated the database yet. Should that be my next step or can should I build my forms and quereys first? If so, which should I do first?

I would probably build data entry/edit form(s) which you can then test as you enter data, then queries and reports. Depending on your data, you may just want to test inputting some, then import the rest.

Thanks, that is what I was thinking. I was just going through a manual and the normilazing chapter was followed by a chapter on queries and thought maybe I should check before I continued.

Thanks for the help

I have found that building the queries & checking they work correctly (data entry allowed etc) to be easier to correct, rather than spending a lot of time on the forms and then finding the underlying query was flawed

there is a bit of stepwise refinement involved - you get an initial design, try using it, and often you have to go back to the drawing board, and refine your design - very hard to be 100% first time

you need some forms to enter the data also - as yuo are likely to have lookups which shouldnt be at table/query level, and validations which may not be possible at table level - user interface isalso highly important

Totally against the book but I generally add data once I have my table structure.. I find this an easy way to know whether your processes are working correctly as you know what the results should be..

Pete666 - not totally against the book at all. Look up "Prototyping" to see why you need to populate your DB enough to get the reports to do something other than "blank page"

I opt to put in some data for general testing as I program. Depending on the complexity, I also write update queries to 'reset' my data (so I don't have to keep calculating the expectation) until I have the general algorithms worked out on the look and feel of the application.

By no means is this general debugging my formal test plan (test, expectation, pass/fail) but it helps ensure everything is relatively smooth in operation before formalizing my test plan, working out the final kinks and publishing the application.

-dK

I rarely populate tables by hand but that is because I am more confident in my ability to create a correct schema the first time. However, I strongly recommend populating tables with reasonable test data before moving on for those of you who are less experienced. You should create queries and try to produce the reports you know about. This will help you determine if the tables work for you or against you.

I just helped out a poster who had a report problem. Technically the issue was that he had a RecordSource for the report when he shouldn't have because he had NO bound fields on the report. Each report control contained a DSum() query and so he had hardcoded 200 controls - 50 rows with 4 controls in each in the detail section and that is how the statistics were being calculated. The real problem was that where he had 50 columns of repeating data, he should have had 50 rows and would have been able to use a single simple query to populate the entire report rather than the 200 he created.