Buidling a complicated query

[Micron]

IMHO, queries before forms. If you cannot enter, update or delete data through a query, don't expect to be able to do so from a form based on such a query. It may be an indication that something is not right with your tables or relationships. IIRC, a Totals, Crosstab or Union query is not updatable, and either those or the lack of joining tables may leave you with the discovery that you've built a form with the intention of creating the record source afterwards and can't use it as planned.

[pbaldy]

I'm more likely to create forms first, but my forms are rarely based on more than one table, so testing first with a query wouldn't gain me anything. I also typically bind forms directly to tables rather than queries. That said, those forms are rarely opened on the whole table; they're either opened in data entry mode or with a wherecondition that restricts the records returned to one or a few. I know there's a school of thought that says "always bind forms to queries", but I never liked school anyway.

I create forms to enter/edit data, testing as I go. I create queries as needed for specific tasks, reports, whatever. So for me in general, tables first, then forms, then reports; queries and code as needed.

[Micron]

I venture to say that your way is less common, but then I didn't like school much either, so what do I know?
Sure, I have based forms on tables, but certainly it has not been my way exclusively. I suspect there more than a few db's out there that cannot function without forms based on queries. It's kind of a result of normalization, and I know I've created a few. I'd say they're the majority, but that's only because my wife says I like to be right...