Re: Cursors

Art S. Kagel wrote: > Nils' suggestion is excellent, however, it does not protect your users > from overwriting data changed by others while he/she is editing the > current record, as Nils points out. Immediately before updating the > record you should FETCH the row that you are about to update with a > CURSOR...FOR UPDATE so that the row is locked and compare the values > returned for all columns, or for an indicative column like a timestamp > or update count, to the original values that you FETCHED. Then only if > the values have not changed UPDATE ... WHERE CURRENT OF <cursorname of > cursor for update>. This will give you the safety of locking rows but > permits greater concurrency since the lock in only momentary. Perhaps you can help me with with doing this in ESQL/C. I'd like to do something like: $ prepare select_id from $select_statement; $ describe select_id into in_vals; $ declare sel_cursor cursor for select_id for update; $ prepare update_id from "update set column1 = ? where current of sel_cusor; $ execute update_id using in_vals; The problem is that $declare will not let me use a prepared statement id with the "for update" keywords. Thus I cannot dynamically set the "select cursor for update". Any ideas on how to do this? Phil -- -------------------------------------------------------------------------- Philip Walden Hewlett Packard Supply Chain Information Systems 1501 Page Mill Road, M/S 5L-A Palo Alto, CA 94304 (415) 857-3899 FAX (415) 857-8234 http://www.pgis.hp.com/~pwalden mailto:phil_walden@hp.com --------------------------------------------------------------------------