Imagine the scene, you’re updating some legacy Sybase code and come across a cursor. The stored procedure builds up a result set in a #temporary table which is all ready to be returned except that one of columns isn’t terribly human readable, it’s an alphanumeric code.
What we need to do, is figure out the possible distinct values of this code, call another stored procedure to cross reference these discrete values and then update the result set with the newly deciphered values:
declare c_lookup_codes for select distinct lookup_code from #workinprogress while(1=1) begin fetch c_lookup_codes into @lookup_code if @@sqlstatus<>0 begin break end exec proc_code_xref @lookup_code @xref_code OUTPUT update #workinprogress set xref = @xref_code where lookup_code = @lookup_code end Now then, whilst this may give some folks palpitations, it does work. My question is, how best would one avoid this kind of thing?
_NB: for the purposes of this example you can also imagine that the result set is in the region of 500k rows and that there are 100 distinct values of look_up_code and finally, that it is not possible to have a table with the xref values in as the logic in proc_code_xref is too arcane._
You have to have a XRef table if you want to take out the cursor. Assuming you know the 100 distinct lookup values (and that they’re static) it’s simple to generate one by calling proc_code_xref 100 times and inserting the results into a table