> > > > What do you do when there is a possibility that several people at once > > are trying to modify the same data ? > > Restructure the application to avoid the conflict. That is what I understood from your previous message, but the following one, and what I also probably would do if possible. Your next answer ... > Failing that I will get the application to re-read the record prior to > saving, confirm that the existing record has not been modified in the > interim and present the situation to the user if it has. ... is really what I thought it would be : you duplicate a function which is already present in the database. I know that the postgreSQL transaction system works this way. On other systems you got locks and blocking transactions. If you can keep these things up outside CGI, then as an application programmer you don't have to reinvent the wheel. > Obviously "present the situation" can cover a number of approaches. > > Although I have written systems to do tricks like merge records where > they are changed by multiple people, I have actually never seen this > happen outside of testing! Well, I do not know about web applications, but I have worked in three different administrative environments (a bank, transports and quality control) and in each one of them I have encountered that two people at a time are trying to change the same data. > Systems I have worked on with few users have usually managed to have > narrow and separated responsibilities, and systems with many records > have always managed to have different people dealing with different sets > of them. The only time there is crossover is when people are off sick, > and of course there ends up being no conflict then either. Regards, Jurgen
