Thread: this is a "If update confirmed, commit, else rollback" question.
Can I (as a superuser accessing the same database and tables of standard users) view any updates conducted by all users, prior to them being committed?
I want to be able to confirm any changes prior to the changes actually being committed to the database.
However the time between a standard user making a change and the superuser actually viewing the proposed changed, could take up to a week.
Any updates are unique. ie: the standard user can only update their own relevant data, therefore data consistency among users is not an issue.
eg: a Rep of mine is going to be late to an overseas client, so they update the database, but I don’t want this to be viewed by others until I acknowledge the update..
I can see that I’ll have to create a temporary tables to do this won’t I......?
thanx...
I want to be able to confirm any changes prior to the changes actually being committed to the database.
However the time between a standard user making a change and the superuser actually viewing the proposed changed, could take up to a week.
Any updates are unique. ie: the standard user can only update their own relevant data, therefore data consistency among users is not an issue.
eg: a Rep of mine is going to be late to an overseas client, so they update the database, but I don’t want this to be viewed by others until I acknowledge the update..
I can see that I’ll have to create a temporary tables to do this won’t I......?
thanx...
From: "Raoul Callaghan" <tangles@bigpond.net.au> > Can I (as a superuser accessing the same database and tables of standard > users) view any updates conducted by all users, prior to them being > committed? > eg: a Rep of mine is going to be late to an overseas client, so they update > the database, but I don¹t want this to be viewed by others until I > acknowledge the update.. > > I can see that I¹ll have to create a temporary tables to do this won¹t > I......? I can see 3 options myself: 1. Temporary tables to hold any updates (think about deletes though) 2. Version numbers on each row, with a separate table tracking "active" version for each row - can be nice if you want to track history. 3. Store the updates (as say the SQL) and then apply them after review. I've found the second useful in an online directory I built where members can update their record but it needs to be reviewed by an editor before "publication". HTH - Richard Huxton