1. Form Development (Chapter 6)
Peter Rob and Elie Semaan Databases: Design, Development, and Deployment Using Microsoft Access
Second Edition

2. Forms: Definition, Use, and Function
Forms play a crucial role in the database applications arena because they help connect the end user to the database. This crucial function is exercised in several ways:
Forms are used to enter new data and to edit existing data. Although this function can, in a primitive way, be met through the use of the datasheet format, using the datasheet for data entry and editing lacks the safety features that forms can provide. In addition, end users demand logically connected and visually appealing interfaces that only forms can supply.

3. Forms: Definition, Use, and Function (Cont)
2. Data entry and edit procedures are subject to human error. Although you learned (in Chapter 4) how to use input masks and validation rules to control at least some input formats and values, input errors must be controlled to an even greater extent. Fortunately, forms may be designed to extend the data validation rules through queries, value lists, and other input control devices.

4. Forms: Definition, Use, and Function (Cont)
3. Forms are used to tie together the database components through menu structures. Therefore, forms enable the applications designer to control database access paths. The use of such access paths can then be controlled through password protection, read-only access, and other security measures. (We will examine security issues and the creation of security systems in Chapter 10.)
In short, it is difficult to conceive of a successful database environment in which forms do not play a dominant role.

5. Form Prerequisites
Given the many roles played by forms and their many structures, you must always begin by defining the details of the conditions that govern form structure and use. Therefore, you should recognize the following possibilities and requirements:
A form may be based on one or more tables. The table(s) must exist before the form is created.
A form may be based on one or more queries. The query (or queries) must exist before the form is created.

6. Form Prerequisites (Cont)
A form may be based on a combination of tables and queries.
If the form is based on multiple tables, the relationships between those tables must be established before you try to create the form. (Naturally, if the forms are based on multiple-source queries, the relationships must be present at the query level.) Those relationships are inherited from the tables or they are created at the query level as needed.

7. Form Prerequisites (Cont)
A form may include one or more unbound controls. An unbound control is a component that does not have a data source attached to it. (A data source is likely to be a table or a query, but it may also be a mathematical expression.) Unbound controls are commonly used to create input spaces, labels, and instructions.
Forms such as dialog boxes and menus do not use any record source. Such forms are created by selecting the Blank Form option from Access.

8. Creating a Form with the Form Wizard
To create a form follow these Steps:
Start at the database window, select the Forms tab, and then click on the New option in the toolbar to generate the New Form dialog box. Also, you can click on Create form by using the wizard on the Forms tab to start creating a form using the wizard.
From the New Form window select the type of Form you want to create and select the Table or Query you want to use as a data source and click Ok to create your Form.

9. Creating a Form with the Form Wizard (Cont)
After the wizard creates your Form select View/Design View from the menu bar to access the Form in design view.
Modify the Form’s presentation format by following the steps explained in section 6.3.
Save your Form.

10. Creating Forms without using the wizard
Forms may be based on tables, or they may be based on queries. (You should recall that the Form Wizard gave us an option to select the data source.) However, forms may also be constructed without specifying a data source at the time of their creation. Such forms may then be used to show query results, listing more than one record at a time. Creating such forms will satisfy two requirements. First, they will enable us to present query results more attractively. Second, they will enable us to use the query results as input for another form, a report, or even another query. This second function will be used to great advantage as we combine the forms we create in this chapter with the macros in Chapter 8.

11. Creating Forms without using the wizard (Cont)
To create a Form without using the wizard follow one of the steps:
Click on the New option in the toolbar on the Form tab, then select Design View from the New Form window, and click Ok.
Click on the Create form in Design view on the Form tab.
Follow the steps explained in section 6.4 to modify your form.

12. Creating a Sub Form
One of the really useful form features is that forms may be linked to other forms to show data relationships on a single screen. The ability to display linked forms simultaneously is particularly useful when you have to process multilevel transactions. For example, if you want to perform invoicing transactions on the screen, it would be awkward to first open the invoice, make an entry, open the first invoice line, make an entry, close the line entry, open the invoice again, and so on, until you are done. You would have the same problem if you would want to examine the past invoices and all their invoice lines. Leaving the relevant invoice on screen while you are scrolling through its lines would be much better.

13. Creating a Sub Form (Cont)
Access makes it easy by using subforms. Follow the steps described in section 6.5 to create a subform.

14. Dialog Boxes
A dialog box is only a Pop Up form which is used to get the user attention or to request an input from the user. Follow the steps described in section 6.6 to create a dialog box.

15. Menus
Menus are used to create fully integrated database applications systems. Menu-driven systems are desirable because they:
Help make the database applications system user-friendly by eliminating the need to remember command languages. Menu-driven systems tend to be easy to learn and use, thus driving down training and end-user support costs.

16. Menus (Cont)
2. Control access by providing only those options that allow people to do their jobs efficiently, shielding the other database options and components from casual use. Although technically knowledgeable end users can easily defeat this aspect of most menu systems, at least the casual end user is less likely to accidentally enter areas that are considered to be off-limits. Similarly, casual end users are not likely to do accidental damage to the database.

17. Menus (Cont)
3. Provide an environment in which system-level database security is easier to create and manage. Although you will learn in Chapter 10 how the database administrator can provide security through various Access security functions, menu systems make it easier to block off portions of the database and its applications. In fact, menu systems can promote reasonable levels of security even in the absence of administrative security measures. The menu systems can also augment administrative security measures by providing password-protected menu options.

18. Menus (Cont)
4. Create an environment that is tailored to specific types of applications and end users. For example, different departments of a business may use customized applications that are easily available only through menu systems. In fact, each department may even have its own menu system, and its end users may be unable to enter the menus of other departments without proper authorization.

19. Menus (Cont)
In short, end users and database administrators like menu systems because they are easy to use, tend to be relatively goof-proof, and fit well into the database security framework.

20. Embedded and Linked Objects
The difference between object linking and object embedding is simple.
A linked object is one that maintains its ties to the originating software. Therefore, if the original object is changed in the originating software, the change will automatically update all object copies that are attached to other objects.
An embedded object is one that no longer has ties to the software from which it was generated. Therefore, the embedded object is not automatically updated when the object in the originating software is changed.

21. Embedded and Linked Objects (Cont)
Use section 6.8 to learn more about Embedded and Linked Objects.

22. The END