Unbound vs Bound Forms (1 Viewer)

[Mike Krailo]

I'm sure this has been brought up many times in various different places but after doing a search, I didn't find a nice one stop shop thread on it explaining the reasoning behind the views (maybe I'm blind). It would be nice to create one single place on the forum where all of our combined experience on this subject can be neatly agreed upon or discussed. If you have specific examples you can share to demonstrate your reasonings one way or the other that will get you bonus points. So I'll throw up some thoughts from Neville Silverman to start things off. I'm sure this will gets some sparks flying. If anyone has differing opinions or experience than what is stated below, just chime in and I can update it if there is a consensus to do so or add a link to your comments on it in the main post. I'm at a cross roads with my thinking on all of this (I'm in the bound forms camp), so I would like to get some of your wisdom on this. Obviously, the below list is incomplete since there are no listed advantages for bound forms. I will add that as we go.

Original Article by Neville Silverman

Disadvantages To Using Bound Forms:

• The default behavior of Access may be unacceptable to users - such as the automatic saving of fields or records
• Cancellation of an update with the Esc key is not user friendly
• There can be performance issues when manipulating data from the Back-End Database
• There is the need to explicitly control record locking
• The Access error messages are not user friendly
• It is difficult to convert a Bound Form to VB.Net
• It is difficult to extract the business rules from the Form logic
• Undoing a change to a field or a record can be difficult
• There is no definite point at which a Record is saved
• Network loads can become a problem (not a fault of bound forms if designed well)
• There is an overhead when a Bound Form is kept open for length periods
• The logic of a Bound Form can get quite complex

Advantages To Using Unbound Forms:

• There is greater control in reading and writing of records
• There is greater control over editing, saving and deleting records
• Records can be updated only when all fields are valid
• There is user friendly error handling
• There is greater efficiency in accessing records
• Reduction in concurrency issues (record in use problem)
• Data integrity can be assured
• The Unbound Form is easily converted to a VB.Net project (see Pat Hartman Post #6)
• Conversion of the Back-End database to SQL Server will be easy

New proposed Lists Below (Updated on 3/22/2022)

Things Bound Forms Do Well:

• There is no need to explicitly control record locking

Things Unbound Forms Do Well:

• Presenting normalized data in a means that cannot be done in a standard single form or continuous form view. (see MajP post #12)

 

[Minty]

I'm sure I won't be the first to disagree on some of these but I'll start;

• There is no definite point at which a Record is saved

Is not true (as far as I'm aware) - I believe that a Forms before update event cannot be got around in normal use.
You can of course update a record in code, but changes to a form's data always trigger this event.

• Conversion of the Back-End database to SQL Server will be easy

This is rubbish. The same applies regardless of unbound or bound.

• Records can be updated only when all fields are valid

Again rubbish if you control your validation in the right event the exact same applies.

• There is user friendly error handling

Only if you program it. No different to a bound form. If the form is designed correctly the end-user wouldn't ever see a plain access error message.

He hasn't mentioned having to trigger any updates based on writing code to capture them.
With an unbound form you have to write your changes back to the source table(s).

There are places for both, but I would say most experienced developers use a bound form, with a restricted record set to perform updates, and unbound forms for special cases.

I could go on, but I'll let someone else chunder in

 

[The_Doc_Man]

There can be performance issues when manipulating data from the Back-End Database

This isn't unique to bound OR unbound forms. It is the SQL that makes or breaks this point.

It is difficult to convert a Bound Form to VB.Net

So? It is difficult to convert any kind of form to any non-Access utility.

Network loads can become a problem

If you don't tune your app to the max on ANY network, it is a problem. Again, it is the SQL that makes or breaks this point.

There is an overhead when a Bound Form is kept open for length periods

True. There is a similar overhead with a non-form recordset that stays open too long. It derives from the locking options (Pessimistic, Optimistic, None) that are in use. Once you have a "window" into a back-end, the longer it is open FOR ANY REASON USING ANY METHOD, the greater the window of opportunity for bad things to happen.

Like Minty, I don't want to hog the comments. Four should be enough for discussion.

 

[Mike Krailo]

This is rubbish. The same applies regardless of unbound or bound.

This task might be harder than I thought. I know everyone has there opinions already but for those of us who have no idea how you came to that conclusion what would be monumentally beneficial to the less informed by giving some reasoning why you think it is rubbish. Your opinion is highly respected.

True. There is a similar overhead with a non-form recordset that stays open too long. It derives from the locking options (Pessimistic, Optimistic, None) that are in use. Once you have a "window" into a back-end, the longer it is open FOR ANY REASON USING ANY METHOD, the greater the window of opportunity for bad things to happen.

This is something that I haven't seen yet but can imagine how that would be a major problem. Possibly programming data entry forms so they time-out to prevent this. I think most web forms do this based on sessions and the session simply times out after a set period.

So far it's looking like we have some rubbish in the original article. So can we correct it? All suggestions are welcome. I'm looking for the main advantages or disadvantages of using bound or unbound with some solid reasons behind it. I knew that article would ruffle some feathers.

 

[CJ_London]

• There is the need to explicitly control record locking

that applies to unbound forms, not bound forms

• Network loads can become a problem

only if you let it

• There is greater efficiency in accessing records

rubbish

• Undoing a change to a field or a record can be difficult

actually easier than when using an unbound form

Seems all a bit one sided - what about disadvantages of unbound forms and advantages of bound forms

 

[Pat Hartman]

Let me not equivocate -- The person who made the list doesn't have a clue how Access works or what it is or why we would ever use it at all instead of using some "superior" method such as vb.net.

All of the "Advantages to unbound forms" are actually true for bound forms with the exception of

• "The Unbound Form is easily converted to a VB.Net project"

That means that the author does not know how to create a bound form or he would never experience ANY of these problems.

If I create an application for an ACE BE, I can convert the app to using SQL Server in less than a couple of hours and it only takes that long because I have to test everything to ensure I haven't overlooked some little used DAO code that won't work as written in SQL Server.

To summarize, Access is not all things to all people. It solves a narrow set of problems that can be solved with forms and reports and simple charts. Access is seriously poor as gaming platform. It cannot be used as a channel program (low level code that controls communications between the OS and some peripheral). But what it does, it does exceptionally well and the heart of what it does revolves around bound forms and reports. It's object model is simple enough for even non-programmers to grasp and without any code at all, create a solution for themselves. These solutions don't meet an expert's definition of solution since they never contain validation code and usually have major normalization flaws so maybe the "expert" who wrote the lists was familiar only with databases created by complete novices. Plus, the thing that makes the conversions to SQL Server fail are the novice's inclination to bind forms to tables with no criteria and use filters to reduce the noise so the user can view what he wants to. When you create an unbound form and then open a recordset of 650,000 rows and use .FindFirst to find the record you want to operate on, do you think that makes the form more efficient? That is the app I am looking at now and the programmer can't figure out why when he converted the BE to SQL server the app got even slower still

Access has a huge footprint. It cannot be used effectively across the internet. It is not easy to distribute. It does not have robust security. And it is extremely difficult to manage a project that has multiple concurrent developers. Once you can get past those drawbacks, it is far and away the most productive platform I have ever used.

 

[Minty]

This task might be harder than I thought. I know everyone has there opinions already but for those of us who have no idea how you came to that conclusion what would be monumentally beneficial to the less informed by giving some reasoning why you think it is rubbish. Your opinion is highly respected.


This is something that I haven't seen yet but can imagine how that would be a major problem. Possibly programming data entry forms so they time-out to prevent this. I think most web forms do this based on sessions and the session simply times out after a set period.

So far it's looking like we have some rubbish in the original article. So can we correct it? All suggestions are welcome. I'm looking for the main advantages or disadvantages of using bound or unbound with some solid reasons behind it. I knew that article would ruffle some feathers.

I'll be a little less verbose

• Conversion of the Back-End database to SQL Server will be easy

A form being bound or unbound has diddly squat to do with converting a back end to SQL server.

How you move the data around and edit it, may well influence the design of the form, but if you designed a bound form correctly in the first place and you moved your data to SQL Server you shouldn't see any difference. E.g don't load every record, load it empty and then get the record(s) you want. You may create a view or stored procedure to get the data quicker, but that again makes zero difference in the actual transfer to SQL Server.

I'm in agreement with @Pat Hartman, I think the author doesn't know or understand Access and is used to writing web pages, with completely unbound record sources.

 

[isladogs]

Agree with all the previous responses.
The author makes sweeping statements about unbound forms providing a more professional solution without any evidence and the points he makes are almost entirely wrong.
For example, converting a BE to SQL Server is completely unrelated to whether the FE has bound or unbound forms. The process is identical whichever type of forms are used.

I've just read another, equally bad, article by the same author

https://ezinearticles.com/?The-Front-End:-Should-It-Be-Written-in-VB.Net-or-Microsoft-Access?&id=7200277

He is described as an expert author! Expert in spouting nonsense

 

[Mike Krailo]

I'm in agreement with @Pat Hartman, I think the author doesn't know or understand Access and is used to writing web pages, with completely unbound record sources.

I think we have establish that the author didn't get the list right. I would like to get your take on what the list should look like.

 

[AngelSpeaks]

I don't understand about the ease of converting to VB.Net. I'm more experienced in VB.Net and I'm not aware of a conversation between the two. I had to recreate bound and unbound forms with the same effort. I do not use the form wizard in VB.Net.

 

[GPGeorge]

I think we have establish that the author didn't get the list right. I would like to get your take on what the list should look like.

I would start with two lists:

1. things unbound forms do well. (complex data validation, for example)
2. Things bound forms do well. (rapid development, for example)

That's the process, at its simplest.

Eliminate everything from both lists that don't relate to the form itself, e.g. the migration from ACE to SQL Server.

If you want to rank each item on your two lists from say, 1 to 10, you can do that. Add up the rankings and produce a subjective result.

 

[MajP]

The Unbound Form is easily converted to a VB.Net project

That does not make any sense, unless this was written before ADO.NET. It is actually the opposite. As in Access, it is far easier to build a bound form then write additional code to pull and push the data. You can build a bound VB.NET form way faster then an unbound vb.net form, so I do not get that. It is harder than doing it in access, but binding a form in VB.NET is pretty simple once you do it once. ADO.NET is pretty damn powerful and feature rich.

1. things unbound forms do well. (complex data validation, for example)

I do not understand that. How does an unbound form allow you to do more complex data validation?

IMO most people who use unbound forms, are because they do not know that you can do the same thing far easier using a bound form.
The authors comparison is not Apples and Oranges, it is a rotten apple compared to a fresh orange. Sure you can build a crappy inefficient bound form, but the solution is to build a good bound form not an unbound form. Also if you want to do the work to use unbound forms why would you waste your time using Access? For free you can get VS and SQL Express, and build far more robust forms than Access provides. The whole reason for using Access is the speed at which you can build an application using the native features.

IMO there is one and only one reason to use unbound form in Access for data manipulation. That is presenting normalized data in a means that cannot be done in a standard single form or continuous form view. Example is this year calendar view. Events are shown in their days and you can click on a day to add or edit and event. It would be extremely hard if not impossible to develop a bound interface.

 

[Mike Krailo]

Eliminate everything from both lists that don't relate to the form itself, e.g. the migration from ACE to SQL Server.

I'll leave the original things on the list per the article but do strike through on them. Then below the original list items, we'll build the actual differences per your suggestion. I'm not too concerned with ranking, just that the list is accurate and based in reality. If anyone has specific examples that can support things on the list, that would be outstanding.

IMO there is one and only one reason to use unbound form in Access for data manipulation. That is presenting normalized data in a means that cannot be done in a standard single form or continuous form view. Example is this year calendar view. Events are shown in their days and you can click on a day to add or edit and event. It would be extremely hard if not impossible to develop a bound interface.

That's the kind of stuff I'm looking for. Thank you MajP.

 

[MajP]

The problem with that article is that it is written from a beginner point of view and most of the Cons of a bound form are really cons of a poorly built bound form. A novice is going to probably use the form wizard and bind an entire table to the form. For small simple databases that is fine. In a very large database you are not going to do that, either bound or unbound. You are going to query the backend and return just the record desired. For the author there is no in between. You either bind the entire table and return all the records or you use an unbound form and query one record. However, that is not what most people do.

If the table is a million records, I can still do a bound form I am just not going to bind it to a table. The author makes it sound as if the only solution is an unbound form. In a million record table I am for sure not clicking through it using the navigation selector, so I am building a search feature to return the record I want. That search feature will return the one record needed. So if designed correctly then there is no performance difference between a bound and unbound form. If you are smart enough to be able to build an unbound form then you should be smart enough to build a proper bound form.

 

[Mike Krailo]

If you are smart enough to be able to build an unbound form then you should be smart enough to build a proper bound form.

You would think, but still I see a lot of effort going into the promotion of bypassing the use of bound forms in favor of the unbound. Maybe it has something to do with web developers that pick up Access and just use what they know from that discipline and apply it to Access. One of the excuses I heard recently was that it made it easier to debug code since they know how their code works but not that Microsoft's little black box of code that works behind the scenes on bound forms. Heck I don't know what's really going on in that black box either but they must have has some bad experiences along the way to come to that conclusion.

 

[MajP]

Maybe it has something to do with web developers that pick up Access and just use what they know from that discipline and apply it to Access.

That may make sense, and answer why you see some over the top coding to do a simple task. If you only have a hammer then everything looks like a nail.

 

[CJ_London]

Don’t know if anyone noticed but both posts are 10 years old.

 

[pbaldy]

To summarize, Access is not all things to all people. It solves a narrow set of problems that can be solved with forms and reports and simple charts. <snip> But what it does, it does exceptionally well and the heart of what it does revolves around bound forms and reports.

Truer words were never spoken.

 

[Mike Krailo]

Don’t know if anyone noticed but both posts are 10 years old.

Yes that's true, but that's what turned up when I searched for the topic. How much has really changed in 10 years anyways?

 

[isladogs]

Yes that's true, but that's what turned up when I searched for the topic. How much has really changed in 10 years anyways?

Nothing in that respect. The author was wrong when the article was written back in 2009

Here's a different point of view by Juan Soto from 2012 on the same topic
https://accessexperts.com/blog/2012/03/13/why-using-unbound-forms-are-a-bad-idea/