[eluser]WanWizard[/eluser]
You usually deal with this at database level, not at application level, as there could be more than one process that wants to modify the same dataset.
To do that, you have to start working transaction based (choose a RDMBS that supports transactions), enclose your queries in a transaction, and do a "SELECT ... FOR UPDATE" to lock the rows you want to update. Other users can still do a select to view the data, but if they also do a "SELECT ... FOR UPDATE" for the same rows. A commit or rollback of the transaction will release the locks.
Note that for most RDBMS's, other lock requests wait until the lock is released. Which means if you do this with persistent connections, set a lock before displaying the form, and then go for coffee, you could lock out other users for a significant period of time. If you don't use persistent connections, locks are automatically released when your script end, triggering a rollback if you hadn't done a commit.
In all, not very practical for your application.
You probably need to go for some kind of semaphore system, either in a database table or using file I/O. Make sure you implement lock expiry, and a cleanup routine, to prevent permanent locks with someone opens a form, sets a lock, then closes his computer for a trip to the Bahamas...