You mention stored procedures and batches but I'm not sure which one you can/want-to use in Sybase so fwiw ...
Sybase, like MSSQL, allows you to declare multiple cursors within the body of a stored proc ... so that shouldn't be an issue (if you plan on using a stored proc).
As for Sybase batches you are correct in that the DECLARE CURSOR must be by itself in its own batch. (How would you do this in MSSQL if not using a stored proc? Does MSSQL not have the same limitation on DECLARE CURSOR in a batch?)
A few ways to feed that variable (from the outer cursor) into a batch-level DECLARE CURSOR:
- see if you can merge the outer and inner cursors into a single cursor that consists of a join between the 2 SELECTs; you'll probably need additional T-SQL logic to keep track of duplicate 'outer' data along with the conditional processing for said duplicate data (eg, keep track of when the outer data set changes values in order to know when to run a new set of outer data related logic)
- declare the inner cursor as a join with a #temp table; during operation you truncate/repopulate the #temp table with the outer cursor's variable's value then open/process/close the inner cursor each time you repopulate the #temp table; obviously (?) the #temp table will only have a single column and row, so we're talking a good bit of overhead just to pass a value to a cursor
- declare the cursor with a WHERE clause that references (via get_appcontext) an ACF (application context function) value; for each outer cursor value you reset the ACF (rm_appcontext, set_appcontext) then open/process/close the inner cursor.
ACF NOTES:
- an ACF basically allows you to store a character string into a sparsely populated associative array; with the use of convert()/cast() you can place non-character data into an ACF; you can think of ACFs as a type of global array/matrix available at a session level
- this isn't what the designers had in mind for ACFs so you'll find little/no documentation on this method in the ASE manuals; if you decide to use/try ACFs and have problems getting it to work ... post back here with what you've tried and I can follow-up with more details
- setting up permissions for ACF access can be a pain in the keister; you have to grant SELECT permissions on builtin functions to a role in the users' default database(s)
- ACF coding can get very messy very quickly, ie, may be hard for follow-on developers to understand
- ACFs cannot be updated, so you have to do a clear (rm_appcontext) followed by a set (set_appcontext)