Solved Save button on bounded Form

[Kingz]

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]

I would have a read here, about how to validate records correctly.

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

 

[Gasman]

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]

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]

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]

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]

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]

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]

I'll open the thread a again with coffee I think

 

[Gasman]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Oh, relationship window,with regards to foreign keys and connections of tables? No there's none of that to consider

 

[Kingz]

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