First Published 7 Mar 2023 Difficulty level : Moderate
Section Links:
What are Split Forms?
Display Issues
Runtime Issues
Code Limitations
Downloads
Replacements to the Split form
Overall conclusions
Feedback
1. What are Split Forms?
Return To Top
This is a companion to my earlier articles: Emulated Split Form and Simulated Split Forms
The built-in Access split form provides two views of your data at the same time — a Form view and a Datasheet view.
The two views are connected to the same data source and are synchronized with each other at all times.
Selecting a field in one part of the form selects the same field in the other part of the form.
You can add, edit, or delete data from either part (provided the record source is updateable and you have not configured the form to prevent these actions).
Despite its appearance, looking at the design view, shows it is a modified single form
NOTE:
In the above screenshots, the built-in split form has been modified to include an unbound combobox to filter the records and a button to clear the filter (see below)
Split forms can also be used to display a datasheet form with a header and additional controls.
In this case, the single record section is deliberately hidden by moving the splitter bar position up to the top of the form and then disabling it
The Northwind example database has many examples of this approach:
To create a split form, click More Forms . . . Split Form on the Create ribbon menu
Although split forms often appeal to new Access users, many developers avoid them completely
Like many experienced Access users, I abandoned the use of split forms a long time ago. They are difficult to adapt if you want to modify them in any significant way.
My criticisms of split forms fall into three main areas:
2. Display Issues
Return To Top
a) Using a standard unmodified split form with tabbed documents display option generally works fine
However, if you use overlapping windows display, controlling the height & width of the form seems to be impossible EVEN if layout guides are removed.
The form seems determined not to allow changes. When the form is reopened, it is always larger in both dimensions than it needs to be.
Even the position of the splitter bar isn’t always retained when reopened . Disabling the splitter does not fix the above issues
Making any significant alterations to a split form can be very problematic as the form often doesn’t behave as expected. For example
b) Using a split form in a subform fails. Only the single form section is displayed
c) Dragging the split form controls to a tab control MAY work OK . . . but see below
d) Placing any object such as a label or subform in the unused form footer section is allowed but causes problems. This is the split form in design view:
In Form View, the form footer items are displayed over the single form controls and partially or wholly cover them.
To fix, increase the detail height or reduce the footer height
Placing the subform in a tab control doesn’t solve this issue.
This is the split form in a tab control in design view. A label has been placed in the footer
In Form view, the label covers the single form section
In the screenshot below, the splitter bar has been moved down to show the single form as well
e) Split forms don’t behave properly with automatic form resizing unless the splitter bar is disabled
Here the single form has been shifted over the datasheet section
3. Runtime Issues
Return To Top
Datasheets are designed so that users can resize/move/hide/unhide/delete fields at runtime.
This can, of course, be useful, particularly in a standalone datasheet form
However this can be confusing/dangerous in a split form where the single form section can only be altered in design view.
Despite this, the single form can be altered by changes to the datasheet section. For example:
A user right clicks on a datasheet field and, possibly unintentionally, clicks Delete instead of Hide Fields.
The corresponding label in the single section immediately disappears (though not the textbox).
If changes are saved when the form is closed, the textbox control is also removed from the single form section on reopening.
Changing the datasheet properties to Read Only does NOT prevent this.
Doing that stops data changes in the datasheet whilst allowing them in the single form (which can be confusing).
The right click context menu still allows fields to be deleted.
Setting the form shortcut menu to No removes the context menu and solves this issue, but of course this also affects the single form section.
4. Code limitations
Return To Top
There are certain things you cannot do in a split form that are possible in all other types of form.
For example, the code context menu does not exist in a split form. To demonstrate this, add this code to the Form_Load event of a split form
Debug.Print Now, "CodeContextObject", (CodeContextObject Is Nothing)
This causes error 2467 in a split form (but works perfectly in ALL other types of form)
Other issues may well have been fixed in recent years. However, in my opinion, with all the above issues, it no longer really matters how many code limitations still exist.
5. Download
Return To Top
Download an example database demonstrating the issues described above:
Split Form Issues (ACCDB file - approx 1 MB zipped)
6. Replacements to the Split form
Return To Top
There really is no need to battle with the vagaries of the standard split form as you can create the same functionality in other ways!
The end result can be almost identical for the end user if you instead create a SIMULATED split form using any of the following layouts:
a) a single main form with a datasheet subform
b) a single main form with a continuous subform
c) a continuous main form with a single subform
Code is needed to keep the form & subform synchronised but this isn’t difficult to do.
The simulated split form can be searched/filtered/sorted as for a standard split form
More importantly, NONE of the above issues still apply. The simulated split form can:
• Be used in a subform or tab control
• Be used with a subform or objects in the footer
• Deletions to the datasheet fields do not alter the single main form
For example solutions using simulated split forms, see my article: Build Your Own Simulated Split Form
Alternatively, the EMULATED split form combines the single and continuous sections in a single form.
This has a further advantage that no code is needed to keep both sections synchronised as each is in the same form
For full details, see my article: Emulated Split Form
7. Overall conclusions
Return To Top
Split forms can work fine provided you use tabbed documents display, don't modify the form and disable the shortcut menu
Otherwise, I would advise you EITHER avoid them completely . . .
. . . OR if you want the split form functionality, it is FAR better to use one of the alternatives available - either SIMULATED or EMULATED
Finally, Richard Rost (MVP) has created a video on split forms that is worth watching. He covers some of the same points as me in his own inimitable style:
The video is available on You Tube: Microsoft Access Split Forms and Why I Don't Like Them or you can click to watch the video below.
8. Feedback
Return To Top
Please use the contact form below to let me know whether you found this article interesting/useful or if you have any questions/comments.
Please also consider making a donation towards the costs of maintaining this website. Thank you
Colin Riddington Mendip Data Systems Last Updated 7 Mar 2023
Return to Access Articles Page
Return to Top