Solved Save button on bounded Form

[GPGeorge]

What The_Doc_Man and LarryE said....

And "...No there's none of that to consider"

Until we get a clear picture of the tables, there's little point in pursuing the "Save" aspect. The underlying problem probably stems from the design as currently implemented, rather than the form.

Actually, it's not uncommon to try to implement coding solutions to compensate for irregular table designs, which means we should have considered that in the beginning. It's time to sort that out.

 

[GaP42]

The

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

No - I do not think so: you have a simple workflow ... someone submits a record/proposal, another reviews and approves the record. If your workflow is never to be extended to more levels then you may structure it as one core table with fields for capturing the needed details and with columns for submitted by and date of submission, and another for approved by and approval date (and an approver notes field). You can control who can edit what depending on role. if you want more flexibility consider Docs suggestion.
The database can be shared, using a split db - the back end data component is shared by multiple front end clients with the same set of queries, forms, reports.

 

[GPGeorge]

The

No - I do not think so: you have a simple workflow ... someone submits a record/proposal, another reviews and approves the record. If your workflow is never to be extended to more levels then you may structure it as one core table with fields for capturing the needed details and with columns for submitted by and date of submission, and another for approved by and approval date (and an approver notes field). You can control who can edit what depending on role. if you want more flexibility consider Docs suggestion.
The database can be shared, using a split db - the back end data component is shared by multiple front end clients with the same set of queries, forms, reports.

The key here is whether there will ever and always be two and only two approvers, not three, four, five, or more approvers for specific situations. The long-term headaches of a repeating column design usually appear after some time, but from then on they persist until the application is abandoned or overhauled. Only if you can gain a commitment that there will never be a third approver for any reason, can you sleep at night.

I'm cognizant that there is supposed to be a second table with two additional approvals, which really calls for additional review and explanation.

 

[Galaxiom]

When both columns are filled with two different usernames, then the dataset is inserted into another table, which will be exported at some point.

The status of a record should not be determined by coping records from one table to another. The tables are the same so they should be one table.

If you can be sure that only two approvers would even be needed then you could add two columns. The "approved" data are the records where both those columns are not Null.

Personally I would use a child table for the approvals so that any number of approvals and further information about them could be recorded.

 

[Kingz]

The key here is whether there will ever and always be two and only two approvers, not three, four, five, or more approvers for specific situations. The long-term headaches of a repeating column design usually appear after some time, but from then on they persist until the application is abandoned or overhauled. Only if you can gain a commitment that there will never be a third approver for any reason, can you sleep at night.

I'm cognizant that there is supposed to be a second table with two additional approvals, which really calls for additional review and explanation.

Well, to answer your question, with regards to the approval. I have two columns "1_Val" and "2_Val". When the 1st person edits something, his pers_ID is entered into column 1_Val, then with the help of the form, I can see which dataset has something in 1_Val, so that when I show that and I want to save, then the 4 eyes concept is fulfilled and I fill 2_Val as well as inserting the dataset into a final master table. Note, if the validator notices a mistake and can't approve but wants to amend, he has to press a button " approval declined", which merely deleted the entry in 1_Val for that dataset, and then he can amend the dataset.. When he saves, his persID will be in 1_Val, waiting for someone to approve it.

Which is why I want/need control of the saving.

 

[GPGeorge]

Well, to answer your question, with regards to the approval. I have two columns "1_Val" and "2_Val". When the 1st person edits something, his pers_ID is entered into column 1_Val, then with the help of the form, I can see which dataset has something in 1_Val, so that when I show that and I want to save, then the 4 eyes concept is fulfilled and I fill 2_Val as well as inserting the dataset into a final master table. Note, if the validator notices a mistake and can't approve but wants to amend, he has to press a button " approval declined", which merely deleted the entry in 1_Val for that dataset, and then he can amend the dataset.. When he saves, his persID will be in 1_Val, waiting for someone to approve it.

Which is why I want/need control of the saving.

None of which actually addresses the issue raised. You are quoting current policy, not the possibility that current policy can be changed at some point.

Is it possible that there will ever be more than 2 approvers required for the initial phase of the process?

Could a future change of policy require 3 initial approvers followed by 2 final approvers?

Can you guarantee that there will never, ever, be a change in policy that requires "five eyes" or "six eyes"?

That's the crux of database design in many similar situations. When you elect a non-standard table design, you lock your process into that non-standard approach in perpetuity. This table design is often referred to as a "spreadsheet style" which means it has two or more columns for the same type of data (approver 1, approver 2). In a spreadsheet you can add a third column, and a fourth column as things change.

In a relational database, which is what you create with Access, that is a non-standard and highly restrictive design approach that usually ends up causing extra work that could have been avoided.

I guess pounding on this point may seem like obsession if you don't understand the problem. It's just that over 25 plus years, this same conundrum has appeared again and again in questions like this one, and the resolution could be so easily implemented.

In the end, though, it's your project and you decide when and how to invest your time and efforts.

 

[Kingz]

No, it will always be two people.. It's called the four eyes principle..I made the two columns extra for that. What I'm asking is for a solution to this problem.. I'm open to ideas

 

[GPGeorge]

No, it will always be two people.. It's called the four eyes principle..I made the two columns extra for that. What I'm asking is for a solution to this problem.. I'm open to ideas

Okay. You know your business.