Share via

Bound vs. Unbound data entry forms

Anonymous
2024-07-17T03:27:58+00:00

I've been using Access for just a few months but have gotten pretty comfortable with it (at least the commonly used stuff). But I'd like to know others' opinions on bound vs. unbound data entry forms. The first database I made, I used a bound form for data entry because I didn't know VBA yet. But I feel like it's a bit unintuitive for end users. When you enter data in a form, you don't expect it to be entered in the database until you click a submit button. But with bound forms, the data is entered once you close the form. No one expects that since that's not what most people are used to (like when entering data on a webpage).

So as I started learning VBA, I made my next few data entry forms unbound with SQL/VBA code behind a submit button. This involves more work, but I think it's almost always better for the end user experience (I'd like to hear other people's opinions though), except in one instance that I've experienced: when you want to include attachments.

AFAIK, you can't submit an attachment field through an unbound form with VBA/SQL (or maybe it's just more difficult) because the attachment itself is a multi-valued field. So if I'm stuck using a bound form for data entry, is there a way to make it more intuitive for users? I played around with it today but couldn't figure out how to make it not enter/save a record if the form is partially filled and the user closes it. I tried using DoCmd.RunCommand acCmdDeleteRecord and acCmdUndo on an unload event. Sometimes it worked, sometimes not.

I'm the only one entering data in this database right now, and it's more for long-term data tracking, not frequent data entry, so including attachments isn't going to be a data storage issue. I just want it to be intuitive and seamless for people using it years down the line when I'm no longer doing this job.

Microsoft 365 and Office | Access | For business | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

27 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2024-07-19T03:14:38+00:00

    Using a form unload event with "If Me.dirty" didn't work the way I hoped, but I found another method that seems to work reliably. My form has checkboxes, which are all Null for a new record. They become non-null as soon as anything is entered in a field, so I used a Form_unload event to check if a checkbox is null, and if not, then cancel the unload event. I guess in a form without checkboxes, I can do the same for a required field? If not IsNull([required_field]) then Cancel = True. Is this the best way to prevent non-explicit entry of new records through a bound form?

    Also, for unbound entry forms, how do I utilize this ExecuteComplete event to give user feedback that an entry was successful, or what went wrong if it's unsuccessful?

    0 comments
  2. Anonymous
    2024-07-18T21:01:34+00:00

    Hi WCZA,

    Bound vs. unbound forms: it depends on what your goal is.

    A quick start without too much coding, choose the bound forms, for versatility and unlimited possibilities, choose the unbound forms.

    I have explored the unbound approach pretty extensive, starting with the form for data entry.

    This has resulted in a systematic where I use only 2 unbound forms in any application. So yes, it is definitily possible.

    But, you must develop all necessary code by yourself. The big problem herewith is that the code must be as structurized as "normalized data" is, to minimize any unwanted side effects. You really must like programming.

    On this moment I have only a telephone available, and no computer, but I can continue after friday, if you like.

    Imb.

    0 comments
  3. ScottGem 68,810 Reputation points Volunteer Moderator
    2024-07-18T08:25:00+00:00

    Except Excel is not a database. It is a different class of program with different usages, strengths and interface. And your premise that data is not saved until submitted is untrue. With Autosave, anything you enter into a cell becomes saved at the autosave timing and without any user action.

    > If a user tries to close a form that is "dirty" they will be prompted 'do you want to save the record'.

    I played around with this today, and it only worked the first time. After the first prompt, the record was (soft) saved and didn't prompt again if I didn't make another change. What did I do wrong? I used a form unload event.

    I suggest you do more research on what "Dirty" means in terms of Access. If you are testing whether a form is Dirty, if there are no changes from the last Save, its no longer Dirty.

    0 comments
  4. Anonymous
    2024-07-18T06:35:26+00:00

    > That is the job of the developer to create a user interface that makes it easier to enter data.

    Right, and to me, I think an unbound form with SQL is easier. Maybe my perspective will change with more experience, but it feels more straightforward having all the data validation checks and insert/append code in one procedure instead of the workaround of having multiple procedures to have the same end-user appearance.

    > I would remind you that Access and its interface pre-existed widespread use of the Web as an interface medium.

    Maybe so, but it post-dates Excel, which is more widely used than Access. Most people are familiar with Excel, and they don't expect data to be saved if they close a form or spreadsheet without clicking save first.

    > If a user tries to close a form that is "dirty" they will be prompted 'do you want to save the record'.

    I played around with this today, and it only worked the first time. After the first prompt, the record was (soft) saved and didn't prompt again if I didn't make another change. What did I do wrong? I used a form unload event.

    0 comments
  5. George Hepworth 22,765 Reputation points Volunteer Moderator
    2024-07-17T12:39:13+00:00

    Yes, I probably over-reacted to the way the task was presented in the original post, along with the implication that the way websites work should be the model for desktop applications such as Access. I'm sure you are sincere in looking for optimal data entry methods and simply need more experience.

    As Ken has shown, there are ways to code around the standard behavior of Access forms. The question, though, is whether that is worthwhile. If you are willing to invest time and effort in learning how Access really does work (as opposed to comparing it unfavorably to the way webpages work), you'll find yourself building effective tools for your users.

    Good luck.

    0 comments