Save button on bounded Form (2 Viewers)

Kingz

Member
Local time
Today, 17:42
Joined
Mar 19, 2024
Messages
38
Hi,

I have a bounded Form with a tab and several text fields and combo boxes.
Now, I only want it to save my input into the fields, when I press the save button, and I can set and check a few things along the way. It seems like it, because it's bound, it saves it anyway. How can I control this?
 

Minty

AWF VIP
Local time
Today, 16:42
Joined
Jul 26, 2013
Messages
10,371
I would have a read here, about how to validate records correctly.
 

Gasman

Enthusiastic Amateur
Local time
Today, 16:42
Joined
Sep 21, 2011
Messages
14,350
Make it unbound?
That is the whole point of a bound form, it saves automatically unless you stop it, because of bad data etc.
You could have a boolean flag that is not set until you press your save button, and only then will the before update process the rest of your rules.
However you are swimming against the tide instead of with it?
 

Kingz

Member
Local time
Today, 17:42
Joined
Mar 19, 2024
Messages
38
Make it unbound?
That is the whole point of a bound form, it saves automatically unless you stop it, because of bad data etc.
You could have a boolean flag that is not set until you press your save button, and only then will the before update process the rest of your rules.
However you are swimming against the tide instead of with it?
Hm..I need a bit of help with the architecture. It's bound so that the information comes straight away from the table, but when I want to save, I need to add a flag to a column.
So with regards to this, is it better to make it unbound, and have the text fields and combos update it self manually?

So I guess, I would then have an before_update() and after_update() procedure. Maybe someone can summarise how that should look like briefly.. 🙏
Thanks in advance.. I'll look at the #2 vid as well above
 

GPGeorge

George Hepworth
Local time
Today, 08:42
Joined
Nov 25, 2004
Messages
1,904
It sounds to me like the proposed "solution" would cost a lot more to implement than it's worth. I think of such things from the point of view of a client paying for the work. Would I like to pay you to invest, say, 10 hours, implementing an unbound form, or would I prefer to pay for 2 hours implementing validation in a bound form? Probably not.

What you are after is called validation. Pat Hartman has done a lot of work in this area and has provided some solid examples and videos. One can be found here.
 

Kingz

Member
Local time
Today, 17:42
Joined
Mar 19, 2024
Messages
38
It sounds to me like the proposed "solution" would cost a lot more to implement than it's worth. I think of such things from the point of view of a client paying for the work. Would I like to pay you to invest, say, 10 hours, implementing an unbound form, or would I prefer to pay for 2 hours implementing validation in a bound form? Probably not.

What you are after is called validation. Pat Hartman has done a lot of work in this area and has provided some solid examples and videos. One can be found here.
Yeah thanks.. This video seems to really tackle the subject.
I thought I was done with a cancel=true in the before_update() , but then it doesn't even open the form now.
 

GPGeorge

George Hepworth
Local time
Today, 08:42
Joined
Nov 25, 2004
Messages
1,904
Yeah thanks.. This video seems to really tackle the subject.
I thought I was done with a cancel=true in the before_update() , but then it doesn't even open the form now.
Show us the code so we can help you identify potential reasons for that.
 

Kingz

Member
Local time
Today, 17:42
Joined
Mar 19, 2024
Messages
38
Sorry guys to bother you with this pesky topic. I tried setting the cancel= true in form_before_update(), that gave me another problem where I set " frm.dirty = false", which is necessary before executing SQLs.. So I'm stuck on what to do.. The video you guys posted is interesting, but I'm just a beginner and I'm quite overwhelmed by it all... All I want is for the automatic save routine to stop, as I've got my own.*weep* :)
 

Kingz

Member
Local time
Today, 17:42
Joined
Mar 19, 2024
Messages
38
I'll open the thread a again with coffee I think
 

Gasman

Enthusiastic Amateur
Local time
Today, 16:42
Joined
Sep 21, 2011
Messages
14,350
If you still want to do it your way, I would leave it bound, but have that boolean flag I mentioned.
It would be set to False on each record if record is dirty. Now where exactly you would set that I am not sure TBH.
Your BeforeUpdate would check this and if still false, exit the event. If True, process the rest of your checks in that event.
Your save button sets that flag to True and then calls that event or moves the record pointer in the form to trigger it.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 10:42
Joined
Feb 28, 2001
Messages
27,218
All I want is for the automatic save routine to stop, as I've got my own.*weep*

If you do the save manually but then perform an UNDO then the automatic save has nothing to save. Hint: There is a recordset underlying your bound form, but there is a usable CLONE of that same recordset (called me.recordsetclone) that you could use to drive your Save process. What you do with .RecordSetClone does not affect the form but DOES affect the recordset that drives the form. If you attempted to do something with the Me.RecordSet (as opposed to its clone), you WOULD affect the form and run into all sorts of "stuff" for which weeping would be a reasonable response.

The thing that many of us are trying to tell you is that you are running into a design / execution problem because you tried to make Access do something contrary to its design, when that something was put in place to help you, not make you weep.
 

GPGeorge

George Hepworth
Local time
Today, 08:42
Joined
Nov 25, 2004
Messages
1,904
Sorry guys to bother you with this pesky topic. I tried setting the cancel= true in form_before_update(), that gave me another problem where I set " frm.dirty = false", which is necessary before executing SQLs.. So I'm stuck on what to do.. The video you guys posted is interesting, but I'm just a beginner and I'm quite overwhelmed by it all... All I want is for the automatic save routine to stop, as I've got my own.*weep* :)
You might share the VBA with us here to make it more possible that specific suggestions could be offered...
 

LarryE

Active member
Local time
Today, 08:42
Joined
Aug 18, 2021
Messages
592
Do yourself a huge favor and just let ACCESS do its job as designed. You are making it much more complicated and as a beginner, you don't need to do that. In fact, no one does. Just:
  1. Bind the form with a query. Don't use the table directly.
  2. Get rid of that stupid Save button. You don't need it with a bound form.
  3. If you wish to validate data before saving it, then use the recommendations given to you for validating data before saving. Using a button to Save or cancel saving data is just not needed. It's a complicated procedure anyway. Just let ACCESS do its job like Doc said. You don't need these complications as a beginner.
 

Kingz

Member
Local time
Today, 17:42
Joined
Mar 19, 2024
Messages
38
Ok, I'll try and explain why I'm trying to stop the auto save functionality, you can tell me a better way of architecture..

With regards to the "four eyes principle", a user is to save a dataset with his username in a column "First", then another user comes to save, and it saves the same dataset in a column "Second" because "First" is not null, saved with a user name. Now column "first" and column "Second" may not have the same username. When both columns are filled with two different usernames, then the dataset is inserted into another table, which will be exported at some point.

How would you combat the save procedure?
 

GPGeorge

George Hepworth
Local time
Today, 08:42
Joined
Nov 25, 2004
Messages
1,904
Ok, I'll try and explain why I'm trying to stop the auto save functionality, you can tell me a better way of architecture..

With regards to the "four eyes principle", a user is to save a dataset with his username in a column "First", then another user comes to save, and it saves the same dataset in a column "Second" because "First" is not null, saved with a user name. Now column "first" and column "Second" may not have the same username. When both columns are filled with two different usernames, then the dataset is inserted into another table, which will be exported at some point.

How would you combat the save procedure?
Whoa. You've introduced another element that truly raises a set of additional considerations.

You have a table with two fields labelled "First" and "Second"? And a second table with presumably the same two fields?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 10:42
Joined
Feb 28, 2001
Messages
27,218
By recognizing that it is possible for an intermediate "save" operation to not be final. In the U.S. Navy we had the "chop chain" concept. The etymology of the terms is worth a separate bit of research, but basically we pushed a record along by having a list of people who had to approve it. For us, engineering approvals included the original implementer, that person's boss, then the security administrator, and finally the government manager. We recognized that leaving the form open on a single computer was a road leading to corruption if the network hiccuped. So what we did is to have a status that said "Record awaiting approval" that was valid regardless of how many had approved it as long as it was waiting for one more approval. If we needed five signatures ("chops", Navy slang for signatures), having none to four signatures merely put the record in limbo waiting for the last chop.

When a record is awaiting its last chop, queries can detect it by finding records with nulls or empty strings in the fields associated with approvals. Note also that this would be a valid case for having a "child" table listing the chops by each authority so that if you needed three chops for some things, four for others, five for the nasty stuff... no problem because what you can do is automatically append the right number of records showing the people who SHOULD enter their chop and having a second column recording that they HAD entered their chop. That way, you can select for records to YOUR attention.

So... you save the record but recognize that the process isn't over. Then you don't worry about that auto save process.
 

LarryE

Active member
Local time
Today, 08:42
Joined
Aug 18, 2021
Messages
592
Ok, I'll try and explain why I'm trying to stop the auto save functionality, you can tell me a better way of architecture..

With regards to the "four eyes principle", a user is to save a dataset with his username in a column "First", then another user comes to save, and it saves the same dataset in a column "Second" because "First" is not null, saved with a user name. Now column "first" and column "Second" may not have the same username. When both columns are filled with two different usernames, then the dataset is inserted into another table, which will be exported at some point.

How would you combat the save procedure?
I wouldn't combat it at all. I would construct my tables and relationships between them so I would not have to. I think we need to look at your overall design before anything else. That will tell the story. Can you post a screenshot of your Relationship window so we can see what the foundation of this system looks like?
 

Kingz

Member
Local time
Today, 17:42
Joined
Mar 19, 2024
Messages
38
What's a relationship window?

It's two tables...Both have the two columns in it. The first table is to make sure the dataset is only coming to the 2nd table (master copy) if it has been validated by two people altogether. What would tend to happen is that the first person corrected or enters the figures, the second approves. So both saves need to come with an update.
 

Kingz

Member
Local time
Today, 17:42
Joined
Mar 19, 2024
Messages
38
Oh, relationship window,with regards to foreign keys and connections of tables? No there's none of that to consider
 

Kingz

Member
Local time
Today, 17:42
Joined
Mar 19, 2024
Messages
38
And when in practice - please tell me if this makes sense - I will have the two tables in a centralised Access DB alone( called it Base), with the main access dB, with the forms, linked to base via linked tables.. So that multiple people can use the mdb with a " first come, first save" functionality
 

Users who are viewing this thread

Top Bottom