Results 1 to 5 of 5

Thread: Form or report?

  1. #1
    Join Date
    Jun 2008

    Unanswered: Form or report?

    I'm still relatively new to Access - this question is due to my moderate experience with forms and my complete and total lack of experience with reports.

    I want to create a report (I use that term conceptually) that prompts an end user to input an assembly number, and kicks out a report that sums up what and how many of each component is used in an assembly.

    So, my first question is - how do I create a report that prompts a user for input? I need to learn this regardless.

    My second question I think confines me to the land of forms and subforms:
    Let's say I wanted a special version of that "report" that placed a control button at the end of each row (one row per component), that would allow me to launch a second report/form, querying this time to show me what other assemblies that particular component was used in and in what quantities.
    Is it possible to do this? Has anyone done this? I'm picturing a subform displaying "continuous forms", one per component - and I need a "bound" control, to allow me to reference data in that particular record, right?

    If I created such a system, where my results were displayed as a continuous form, is there any way to nicely print the resulting form/subform in it's complete form? A printable form if you will? Or will I be limited to "screen-shot" type printing capabilities?

    Thanks for help!

  2. #2
    Join Date
    Aug 2006
    The answer to your first question is that it would be done using a Form, NOT a report. The report is just the data on a given record which a user can either VIEW or default to PRINT to the local printer.

  3. #3
    Join Date
    Jun 2008
    I had a thought that I could create a query with a WHERE clause that references something that doesn't exist, like "WHERE AssyPN = [UserInput]".

    Then, I could build a report off that query...
    And build a message-box type form with a control called "UserInput" asking the user to input the assembly he wants to limit the report to, and launching the report when the "OK" button is pressed.
    I don't know if the scope of the variable will still be alive if I did that though-
    does the query inherit what's active from the form since it's bound to the report?

    The layers would go like this:
    Form --> Report --> Query
    In other words, does it behave like this?
    Form --> [Report --> Query]

    The former would possibly not map "UserData" in the query to the "UserData" form control.
    The latter would allow me to reference the "UserData" control in the query.

    Anyone know which situation reflects reality?

  4. #4
    Join Date
    May 2008
    Raleigh, NC

    Answer to #1

    You can require the user to put in what you want, you just have to do it in the underlying query. You use "WHERE AssyPN = [UserInput]" as your example and if the query has the column AssyPN, just place [Your Desc Here:] on the criteria line under this column and an input box will appear when the query is run prompting the user to put in a value. You will have some code in case the user leaves it blank or puts in a bogus number, but that isn't too difficult.

    Good luck, Stu
    --If its free, take it for what its worth!

  5. #5
    Join Date
    Jun 2008
    I understand - I like knowing that I can put a sort of pseudo-prompt in the "criteria" line in that query builder...
    That could save me a lot of work in creating a form just to basically present the user with the same sort of message box prompting them to input that info!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts