Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.


this is not a question. It's a solution. Maybe it's an doc enhancement request. :)

We need to process multiple result sets (coming from a CLR external procedure. It took me half an hour to get this running and I just want to share the solution with you. The key is the RESUME statement. I think there should be a usage example of it in the "SQL Anywhere Server - SQL Usage » Stored procedures, triggers, batches, and user-defined functions » Result sets" section of the documentation.

Here's the sample:

create or replace procedure ResultSetTest()
    select  'OK'            ProcResult
            , 'No messages' ProcMessage;

    select  Id, Surname, GivenName
    from    Customers
    order   by Id;

create or replace procedure ResultSetTestConsumer()
    declare customers cursor for 
       call ResultSetTest();

    declare @Id         integer;
    declare @Surname    person_name_t;
    declare @GivenName  person_name_t;

    declare @ProcResult     char(10);
    declare @ProcMessage    long varchar;

    open customers;

    fetch next customers into @ProcResult, @ProcMessage;
    message String('[', @ProcResult, '] ', @ProcMessage) type info to client;

    if @ProcResult = 'OK' then
        resume customers;

        lp: Loop
            fetch next customers into @Id, @Surname, @GivenName;
            if SQLCODE <> 0 then leave lp end if;
            message String('(', @Id, ') ', @Surname, ', ', @GivenName) type info to client;
        end loop;
    end if;

    close customers;

call ResultSetTestConsumer();

asked 13 Jul '16, 05:28

Michael%20Fischer's gravatar image

Michael Fischer
accept rate: 25%


A really helpful suggestion - and a DCX comment might be worthwhile...

FWIW: For old-school users of dbisqlc, the RESUME statement is not that unfamiliar - it's the only way to receive more than one result set of a procedure: :)

alt text

(13 Jul '16, 06:20) Volker Barth
Replies hidden

Good point, Volker, just added a comment on DCX for SQLA17 under the "Result Sets" topic.

(13 Jul '16, 07:50) Michael Fischer

Some of this is covered in the DCX article Store procedures with result sets at the bottom; almost as an after-thought/footnote. But I agree it would be awkward/difficult to map the information from this (Embedded-SQL-centric) article to a PSM usage ... for instance you were able to bypassed the need to describe the new result set (something that is not a PSM concept anyway) by knowing what this new result columns look like and directly representing that in your Fetch-Into statement.

There are numerous other DCX articles that cover this for client apps (dbisql not dbisqlc) and APIs ODBC, JDBC, Ruby, etc ... so maybe it makes sense for this to get it's own article. It does seem to be something that probably was not as much of a requirement since procedures usually are the 'return-or-of' multiple sets and less commonly a 'return-ee-for' multiple result sets and don't often have a needs to retrieve them.

Some possible caveats: this is a Watcom SQL behaviour (and not only becuase the RESUME statement is proprietary), ... and T/SQL stored procedures will likely behave differently. That latter caveat not being a concern for this case but may be important for other readers of this thread to be aware of.

permanent link

answered 13 Jul '16, 12:56

Nick%20Elson%20SAP%20SQL%20Anywhere's gravatar image

Nick Elson S...
accept rate: 32%

edited 14 Jul '16, 10:31


it is indeed the first time since starting with Watcom SQL that I need to do this. In a plain SQL world we would find better designs. In our given real-world situation, the ResultSetTest()-Procedure is a proxy proc to an external CLR call that shall return both elaborate diagnostic information if something went wrong (first result set) and the actual data (second result set) if everything is ok.

I'm open for sugestions. Do you see a more elegant way to design that external interface?

(14 Jul '16, 04:56) Michael Fischer

Does it need to be one single procedure call?

Or could you split up the functionality into, say

  • a procedure that returns the actual data as result set (empty in case of a failure) and an addional return code that tells about success/error, and
  • an additional procedure that returns the diagnostic data if a failure has occured?

(Apparently that split assumes that failures are reproducible or that their diagnostic details are stored internally so the second procedure has that information available...)

Note that SQL Anywhere requires the caller of a procedure with both a result set and output parameters/return value to fully fetch all result sets before the parameters/return value are available, as stated by Mark here. (For that reason, I usually do only use one of both ways to return data...)

(14 Jul '16, 10:22) Volker Barth

Another possible thought ....

Maybe your 'elaborate diagnostic information' would fit better into some sort of structured object ... say HTML or XML maybe? The would then only require a static blob/clob to be fetched.

Both the .Net framework and possibly your ultimate content serving source may be able to provide that.

But if you are consuming the result from a pre-exisiting or third party component that does not support a different paradigm then you will be locked into the current approach.

(14 Jul '16, 10:38) Nick Elson S...
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 13 Jul '16, 05:28

question was seen: 2,979 times

last updated: 14 Jul '16, 10:38