I have a multi-file solution where data manipulation is done in one file and all else is done in others. I find transactions a challenge when changes to security settings are involved.
The security settings in this solution are "tied" to a table that contains account names, no password, and user preferences. The table's interface allows for the creation / modification / deletion of records and their tied accounts (using only temporary passwords when needed).
All record creation / modifications / deletions are done in the data manipulation file. Security settings being a non-sharable per-file thing, changes to it must be done in all files. That's the rub!
I ideally want transactions to encompass the creation / modification / deletion of a user records and their tied accounts. My challenge: transactions cannot encompass multiple files; using error capturing methods is complex and fails utterly during crashes.
Anyone have a simple(ish) solution? The only I can think of is quite complex.
I've used this in quite a few systems and it works well.
users login using an account which is in Accounts table.
On login, link user info to a session record
Re-login to a generic permissions group, e.g., POS, Manager, Receivals.
The generic permissions group accounts are standard in all files in the solution. So login between files is auto-magic.
The session record is linked in all files so that the user's unique details are known.
Also worth noting that rules such as "data may only be modified in file X" may need questioning. If file A has a reference to file B - all other things being equal - the changes to data belonging to file B are most sensibly made using the file that the user is currently using. That could be file A or file B.
Had to think about this a bit. Quick answer is no. It would require the administrative users (there are two levels of these users) to use multiple systems to manage accounts and users.
This is related to managing user records and managing accounts as a transaction. If a record or security account action fails, all should fail as if a transaction.
I find your proposal interesting. I will see if it could work in my solution and what it would take to implement it.
As for the "data may only be modified in file X"…
We use the MVC design pattern. Modifications by scripts to tables are only done by the model. Those done by users are done by the view.
All model scripts are contained in the model file. Yes… the model scripts could be in any file. This was done in the past with disastrous results so it was decided to try the current approach and see if we would have better outcomes. The outcomes are better so far.
Don't get me wrong! There are a few disadvantages, however we feel the advantages outweigh the disadvantages so far.