Solved A Really Simple Question (2 Viewers)

[Pat Hartman]

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.

If your query is not updateble, your form is not updateable. So, nothing is required to "guard" it. Since the OP's query aggregates data, it is not updateable.

I do not think Pat would have any argument about a read only unbound form in single form view (maybe I am wrong).

Of course not but why?

Once you need CRUD or even the ability to scroll, you should just make a bound form. There is nothing inherently better about an unbound form. You will know based on your work with an app to date, whether you have to even consider unbound forms. You will more likely need to use an unbound form if you are connecting over the internet to your BE. Since very few applications actually do that, there are very few applications where you would even consider the possibility of starting with an unbound form unless you're getting paid by the hour and your client is clueless.

There are certain business scenarios where you have to enter all the child records before you commit a parent. Some people choose to use unbound forms in that case. But there are other, simpler solutions such as shadow tables that are used to create and validate the set of data before committing to the production table.


For the case in the original question, there is simply no reason to even consider using an unbound form although the amount of extra work to do so for a single record, noupdatable form is negligible.

The OP will be far better served by learning how the form's event model works so he can use the features of the RAD tool to control how bound forms and reports work. Here some videos and a sample database to work with to help you learn how the form's event model works. Use the existing forms or create your own and add them to the sample. Use the sample to investigate control events also. You can even add reports. Just follow the pattern and use the one line of logging code in any event you want to follow.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk

 

[Edgar_]

You can use the unbound form, nothing bad is going to happen to your business if you want to show a read-only piece of data.

If your query is not updateble, your form is not updateable. So, nothing is required to "guard" it. Since the OP's query aggregates data, it is not updateable.

You had to tweak the thing for that to occur, period. The unbound form does not need that extra pattern to be maintained. It laser focuses on presenting the data in a neat way and goes away. No side effects. Oh, and it can be reused like a component for any other similar thing.

 

[Papa_Bear1]

I think I'm seeing the pros/cons on this. I've really only ever had occasion to use bound forms. I've had occasions to use unbound controls.

This just happened to present itself - due to its simplicity - as a case where I *could* choose to make the form unbound, and was just wondering if there was a compelling reason to do it one way or the other.

It still looks like a coin toss - to me at least - ha.
And, I've left it as a bound form - the way I initially created it, as there just really wasn't a compelling reason not to.

I appreciate seeing all the info on this topic. Thanks to everyone!!

 

[Papa_Bear1]

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.

Well - I would say that the form I'm working IS the one where the user chooses whether to perform the maintenance or not. It is true that I could probably just put up a YesNo MsgBox, asking for confirmation - but - I wanted to show them the path to the file they recently imported *while* asking for confirmation - and I didn't want to cram all that into a MsgBox. Hope that is making sense. Always lots of ways to do the same thing!

 

[Papa_Bear1]

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.

Just trying to close the loop on some of the comments...
I think I updated my comment after your comment --- as I did not have them open at the same time. Indeed that would be a little bit crazy -- ha. I think the issue I've had is probably changing data on the form that is open - perhaps without saving it - and then there is a Write Conflict - that kind of thing - but - I'm not even sure - it's been a long time since running into that scenario. Anyway - totally agree with your point!!