Anyone that has created a continuous form is well aware of the new entry blank row appearing at the bottom of the form.
Although this is functional, let’s face it, it is less than ideal! Continuously having to scroll down to the bottom, or even having the new row hidden completely out of sight does not enhance the user experience. Furthermore, if you apply default values to your controls it can end up confusing your users as they will think they are actual rows of data rather than a row for performing data entry.
So I thought I’d create a very simple demo database to illustrate a couple alternative approaches to implement within a database to simplify your end-users’ lives and up your game as a developer.
As you will see for yourselves, the alternatives are remarkably simple to implement and require less than 5 lines of code!
In all cases, the code used is minimal and very primitive and thus will work on any version of Access.
Preview of the demo
Data Entry at the Top of the Continuous Form
This is a fully customizable data entry form. Below has purposely been made to stand out with large buttons, but you can also set the form up to seamlessly integrate into the existing form and your users wouldn’t have a clue that it wasn’t a standard form. The choice is yours at the end of the day.
Using a Pop-Up form for Entering New Entries
In this approach, we simply call a pop-up form to perform the insertion. This actually works really well, maximizes the main form’s space for displaying records in the continuous form and mimics what users are used to seeing on the internet.
It is surprising to see just how simple it is to improve your forms and the data entry process with such a minor, but effective change.
Disclaimer/Notes:
If you do not have Microsoft Access, simply download and install the freely available runtime version (this permits running MS Access databases, but not modifying their design):Microsoft Access 2010 Runtime
Microsoft Access 2013 Runtime
Microsoft Access 2016 Runtime
Microsoft 365 Access Runtime
In no event will Devhut.net or CARDA Consultants Inc. be liable to the client/end-user or any third party for any damages, including any lost profits, lost savings or other incidental, consequential or special damages arising out of the operation of or inability to operate the software which CARDA Consultants Inc. has provided, even if CARDA Consultants Inc. has been advised of the possibility of such damages.
Download a Demo Database
Feel free to download a 100% unlocked demo copy by using the link provided below:
Download “Access - Continuous Form Data Entry Approaches” ContinuousForm_DataEntry.zip – Downloaded 11737 times – 58.40 KBDownload Version History
V1.000 (2017-11-10)
Initial release
V1.001 (2017-11-12)
Added examples of using unbound forms for both alternative methods to get around the issue of consuming PK numbers if the users cancelled the insertion of the new record.
V1.002 (2024-03-23)
Fixed a potential bug with the Reset command in bound forms.
I have tried to implement the above entry method but I cannot get the continuous form to show more than one record. I’ve downloaded the demo and mimicked all of the code and settings.
The first and most important property your need to set is the form’s Default View which you must set to Continuous Forms. Start with that and post back if that doesn’t get you going.
Thanks for the demo!
Could you explain a little more about the bound form vs the unbound form. I don’t really understand the difference.
A bound form has a record source defined, typically a table, so when the form is opened, used, it is directly editing the records from that source. Think of it as being directly linked to a table.
An unbound form, is not linked to a table. It is kind of like a blank form. It is through coding that it retrieves it’s data, or binds to its source.
Most common Access databases, the vast majority, that are developed use bound objects, but sometimes it can be advantageous to use unbound forms. For instance, by not binding the form, it can load instantaneously rather than having to fetch data. Then the form might have a lookup feature that would then go retrieve a single record (instead of the entire source).
Unbound forms are more complex, require more coding, but can be optimized to be very efficient! That all said, unless you have a particular reason, stick with bound objects/forms/reports.
The continuous forms approach addresses a serious shortcoming in the standard features of Access…thanks. It is exactly what I needed.
A general note regarding the current Poll. It is actually two, very different, questions. As to the second, I am definitely starting new projects. I have used Access for years and am comfortable with the interface. It provides rich solutions for a Windows operating systems (although I am not aware of how it functions in a Mac environment). As to the relevance question it is very relevant to me. But the massive move to tablets and phones using Mac or Android operating systems makes its broader relevance questionable.