Re: BEGIN/COMMIT work in Stored Procedure

Fred Prose wrote in message <44C2247EAFF4D011B0BD00805F85B09C0C0526B8@news.maricopa.gov>... >What is the prevailing thought about using BEGIN/COMMIT WORK within a Stored >Procedure? > How do you know the procedure isn't already within a BEGIN/COMMIT WORK ? I see here many opportunities for big mistakes. >I've got a SP which is called to obtain and increment a "next serial number" >column. This potentially will cause a bottle nexk and I'd like to have the >SP "get in and get out" ASAP. > >Any other suggestions to make sure the SP isn't doing any dirty reads? > 1. make the "serial" a unique column and test for duplicate inserts. Good for table with few changes, bad for busy tables. 2. As suggested in another thread, create another table with only a serial column, insert a new row and get the inserted serial. Only works if the serial is the only field in the key and not the last field of a logical key. >Thanks, > > > C.