A Really Simple Question (3 Viewers)

[Papa_Bear1]

I've pretty much always used bound forms, and have only rarely needed to do otherwise. But, while looking at one of my very simple forms recently, it occurred to me that I wouldn't have to use a bound form to show this one particular piece of data. I could, instead, use a function (that I wrote for an unbound control in another form actually... so, I have the function already...) to retrieve the value, and place that value in an unbound control on the same form, and make the whole form unbound as well.

My question is: Is there any real benefit to having a simple form like this unbound?

------
Some of my thoughts while trying to answer this myself:

1) I've read/heard that keeping a bound control open for a long time, perhaps that has a lot of data in it, etc., could pose some problems. In this particular case - it is eminently simple - like one field and one button - and won't be open for long. So this line of thinking is probably N/A.

2) I've had occasions before where trying to use multiple forms bound to the same table - but at different times - (in a case like this that is a "UserOptions" kind of table with just one row...), when combined with other SQL operations, has caused some unexpected record-locking. So, in the back of my mind, I wonder if this might be one advantage to being unbound here. It reduces the number of forms trying to use the same table.

------
Just curious if there is an obvious answer - or if it is just another one of those fuzzy areas.

Thanks in advance for any insight.

 

[theDBguy]

It's hard to say if you should use a bound form in this case or not. Typically, you should use a bound form when you can if the data on that form are stored in a table. If you didn't want the user to edit the data, you could make the form read only. As you already know, to use an unbound form, you'll also need extra work like the function you mentioned.

 

[plog]

I only use unbound forms for menus. If I want the user to act on the data (create, update, delete) I use bound forms. Even if I want the form to be read only but I wanted to display a lot fields from a datasource I would still use a bound form, but just disable everything.

Bound forms are easier.

 

[GPGeorge]

Bound forms alleviate a lot of the "plumbing" that goes into both CRUD operations and data display. If one particular control can augment the data in the form's recordsource with relevant but unrelated data, and there is no need for data validation or data operations on any of the data, I can see adding it in an unbound control, though. If that's less work than figuring out how to incorporate it into the form's recordsource, it might be proper.

 

[The_Doc_Man]

OK, first, I'm a pragmatist. If it works for you, well and good. But... The answer to your question depends on the purpose of your form.

You have a function to collect (or compute) this item from where it sits and display it in an unbound control. That means it has some functional meaning to you. It is something you want or need to know. You discuss putting this unbound control on a totally unbound form. This leads to the question of why the form exists.

I have used unbound forms as "switchboards" to launch functional forms, and the unbound dispatcher forms DID have unbound things on them like date and username and some statistical things - but the unbound forms always led somewhere.

I guess the real question is, what is this value and how did you intend to use it? Without knowing that, it is hard to us to decide whether you should or should not use an unbound form.

 

[MajP]

Just curious if there is an obvious answer - or if it is just another one of those fuzzy areas

No there is not a simple answer, but IMO the time to use an unbound form is very small. I am not saying there is not a place for them, but 99% of the time when I see people do this it is unneeded and usually it is ten times as complicated as it would be to do it bound. The one that drives me nuts is the novices that got convinced by reading something they need a complicated unbound form, but they do not know the basics to do it much simpler bound.

Often when someone thinks they need an unbound form it is because
1. Something much bigger is wrong in the design to start with
2. They do not know the capabilities of Access bound forms
3. They come from a coding background so they have a hammer and everything looks like a nail
4. They are thinking about it wrong. For example they want a save button, which is equivalent to thinking you need some feature to start bleeding when you cut yourself. Pretty much going to happen.

These are some of the common things I hear
"I need an unbound form because I want a save / cancel button and you need to do this unbound" Wrong!
"I can ensure better data integrity " Wrong.
"I need to control the program flow better" Wrong.
"Blah blah " Wrong.
"I need to show data from multiple tables" Wrong.

I will caveat this to mean unbound "traditional" forms. Forms that could be done bound. There is another group of unbound forms that cannot be done in a native form, subform way. Things like treeviews or calendars. Now that I am a fan of.

Access is a rapid development application (RAD) and it is very powerful for building bound forms quickly. If you filled compelled to "out smart" access and do things unbound, it is really not a very good development environment. If someone wants to put a lot of effort into coding unbound forms then they could do it in visual studio and would have way better design capabilities.

 

[Edgar_]

Is there any real benefit to having a simple form like this unbound?

Of course, you have the benefit of just fetching the data that needs to be displayed and have nothing else going on.

I've read/heard that keeping a bound control open for a long time, perhaps that has a lot of data in it, etc., could pose some problems. In this particular case - it is eminently simple - like one field and one button - and won't be open for long. So this line of thinking is probably N/A.

Well, in network scenarios, losing connectivity can lead to data corruption and may cause Access to crash. If your app is open for a long time, losing access to the network could take place for a number of reasons. It's not specific to bound forms, but it would happen less with unbound forms.

I've had occasions before where trying to use multiple forms bound to the same table - but at different times - (in a case like this that is a "UserOptions" kind of table with just one row...), when combined with other SQL operations, has caused some unexpected record-locking. So, in the back of my mind, I wonder if this might be one advantage to being unbound here. It reduces the number of forms trying to use the same table.

That's probably a design issue, more than a bound vs unbound argument.

Just curious if there is an obvious answer - or if it is just another one of those fuzzy areas.

If you don't want to deal with the side effects - or side benefits - of a bound form, use the unbound alternative. Not all choices are made because of technical aspects.

TL;DR
If it makes sense, use them. Your context is very important.

 

[NauticalGent]

If you filled compelled to "out smart" access...

Never ends well, ever...

 

[arnelgp]

TL;DR
If it makes sense, use them. Your context is very important.

You are more right than All the wrongs. -1952

 

[Papa_Bear1]

Thank you all for your advice and insights!

I definitely concur with the general principle that Access offers tons of built-in features with bound forms, and honestly - I can think of only a handful of times over many years that I may have not used a bound form! (Unbound controls, I've had more occasions there...)

It sounds like there isn't any particular issue - like memory management or anything like that - which would make this choice obvious one way or the other - especially since this is a very simple form.

@Edgar_ Thanks for your specific answers.
@The_Doc_Man & @Edgar_ You asked about the context/purpose. This form serves only to remind the user of their last import Path\File, and then lets them run a data maintenance utility - or not. That's pretty much it, so I'm making the info I'm presenting disabled/read-only. I just wanted the user to have a chance to see what the data source was before choosing whether to proceed with the process. I suppose I could forego showing them this info and/or just use a MsgBox, but I wanted the nicer display of a normal form.

 

[Papa_Bear1]

Never ends well, ever...

Indeed... As - I've tried - and I usually end up abandoning all hope...

 

[Papa_Bear1]

Bound forms alleviate a lot of the "plumbing" that goes into both CRUD operations and data display. If one particular control can augment the data in the form's recordsource with relevant but unrelated data, and there is no need for data validation or data operations on any of the data, I can see adding it in an unbound control, though. If that's less work than figuring out how to incorporate it into the form's recordsource, it might be proper.

Funny thing - about all the "plumbing" needed for unbound. It reminds of when I tried to build a web page (years ago) - after only ever having worked in Access. Wow did I take that plumbing for granted! Trying to present a simple form on a web page that walks the user through a series of records was a major pain. The web page inherently had no memory of where it was, so navigating between records was amazingly difficult.

I'm glad I've been able to use Access to solve some user challenges - I LIKE the environment - a LOT. Is it limited? Sure. But as long as you stay within the bounds of what it is good at - you can build some pretty nice stuff - and quickly.

 

[The_Doc_Man]

This form serves only to remind the user of their last import Path\File, and then lets them run a data maintenance utility - or not.

Here is MY question: Why have another form at all? On the form where you would choose to perform maintenance, include this unbound value and have some option, maybe a command button, on the form to do or not do the maintenance step. Assuming, of course, that you have only one maintenance step to be performed. Your description is a bit hazy in spots but it SEEMS like you would have fewer steps for your user to consider if the information about pathing and the form to do the maintenance would be in the same place. Just thinkin' out loud, not criticizing.

 

[Pat Hartman]

My question is: Is there any real benefit to having a simple form like this unbound?

Access is a RAD tool. It's best feature is bound forms. The point of using a RAD tool is that it does stuff for you. While there are occasions where you may decide to use an unbound form, I wouldn't go out of my way to do so. It is always more work. Make sure you have an actual reason to take on the extra coding effort.

 

[Pat Hartman]

2) I've had occasions before where trying to use multiple forms bound to the same table - but at different times - (in a case like this that is a "UserOptions" kind of table with just one row...), when combined with other SQL operations, has caused some unexpected record-locking. So, in the back of my mind, I wonder if this might be one advantage to being unbound here. It reduces the number of forms trying to use the same table.

Why would you have multiple forms bound to UserOptions open at the same time? And in update mode no less?

When you are writing a complicated procedure inside a transaction and it requires updates to multiple tables, you need to be conscious of the deadly embrace scenario. Where App1 locks tbl1, tbl2, then tbl3. But App2 locks tbl2, then tbl3, then tbl1. You need to think about this when writing your code so you always lock the tables in the same order to prevent the conflict.

 

[Pat Hartman]

Of course, you have the benefit of just fetching the data that needs to be displayed and have nothing else going on.

You can control what you fetch for a bound form by using a query with parameters. This is not a reason to use an unbound form. See reply #6. I agree with MajP. Most of the posters who use unbound forms are using them for the wrong reason and therefore wasting a lot of programming effort for no reason.

 

[Edgar_]

You can control what you fetch for a bound form by using a query with parameters

Oh yeah, but your form's bound, so you gotta disable stuff here, add guards there, fix this, fix that. Not exactly a high IQ move for a simple read-only feature. Honestly, it's like bringing a tank to a pillow fight. You don't need all that. Believe me.

Most of the posters who use unbound forms are using them for the wrong reason and therefore wasting a lot of programming effort for no reason.

Look, you've seen bad implementations, total disasters, OK. And now you wanna blame the tool? Come on. You wanna pile on more parameters, more hoops, more nonsense. Define a list here, set it there, then spend all day chasing that annoying little message like it's your worst enemy. You really think complicated means better? Wrong, totally wrong. Believe me, less is more. Clean, fast, efficient. Tremendous, absolutely tremendous. OP was using it for read-only stuff. Incredible, great. To the point.

And nobody talks about this, but that big, beautiful unbound form? It can be reused. Reused! Incredible. Don't wanna use unbound forms? Sad! Very sad!

 

[Imb]

And nobody talks about this, but that big, beautiful unbound form? It can be reused. Reused! Incredible. Don't wanna use unbound forms? Sad! Very sad!

@Edgar_

I only use unbound forms, and to be specific, only two for all applications.
Binding is necessary for the control to know where to get its information, or where to store it. In my applications I use a "dynamic" bonding, that is, in the Enter event of any control the whole binding and checking for that control - if relevant - is done.
In this way you can automate all CRUD operations. And many more.

To speak with @Pat: the RAD-tool is converted to a SuperFast RAD-tool!

Imb.

 

[MajP]

@Edgar_
I think you and @Pat Hartman disagreeing on different things. I do not think Pat would have any argument about a read only unbound form in single form view (maybe I am wrong). Sure that is quick and easy and is a valid choice for an unbound form. But like her that is not what I see people coming to the forum with problems. In fact I rarely ever seen a question about a read only unbound form. It is when they try to replicate CRUD with a way over complicated design. Often it is something that if done right bound would take 10 minutes to build bound but it is taking them days to replicate it unbound and there is no real need. And almost never do their reasons to do it unbound really make sense. Most of the time it is that they perceive some limitation in bound forms, that does not exist. I do not think Pat's response or mine was directed to the OPs specific case of an unbound read only form, it was in general to what we see on the forum when we see users come with unbound Rube Goldberg solutions to what can be easily done bound.