To expand on Mark's answer: One way to create a separate thread and connection is (in PowerBuilder) to call SharedObjectRegister and SharedObjectGet. Another way is to call a stored procedure which triggers a server-side EVENT to perform the actual task; events run on their own connection, and TRIGGER EVENT is a fire-and-forget operation. I've used the former technique to make up to 1,000 connections to SQL Anywhere for stress-testing purposes. The latter technique (TRIGGER EVENT) is at the heart of Foxhound.

There are at least three reasons to use asynchronous calls to ODBC:

1. Your application should be responsive during longer-taking queries. - That is primarily a historical need, methinks: Starting with the introduction of 32 bit OSes, one should implement that requirement with a separate thread doing a synchronous ODBC call instead of an asynchronous ODBC call in the main thread.

2. You want to be able to cancel a longer-taking query. - AFAIK, in order to cancel a running ODBC query in SA, you will have to use a second thread and call SQLCancel() with the statement handle from the first request. That is a side-effect of not-supporting asynchronous calls.

3. You want to display progress messages during longer-taking queries. - That seems to be your particular concern. - In SA, you can use MESSAGE TO CLIENT statements in your SQL code and use a particular callback to receive those messages. You may have a look at SA_REGISTER_MESSAGE_CALLBACK for that usage.

Please not: These hints are taken from my personal memory, so I'd like to invite all SA insiders to verify my statements:)