Quote Originally Posted by raveens View Post
Bump and also a re-thinnk of the original suggestion.

Instead exposing the ASYNC attribute which may not sit well in DF's single threaded environment, maybe the better approach would be the asynchronous execution of SQL statements internally within the {driver}.dll - see example below:

Code:
SQLHSTMT  hstmt1;  
SQLRETURN rc;  
  
// Specify that the statement is to be executed asynchronously.  
SQLSetStmtAttr(hstmt1, SQL_ATTR_ASYNC_ENABLE, SQL_ASYNC_ENABLE_ON, 0);  
  
// Execute a SELECT statement asynchronously.  
while ((rc=SQLExecDirect(hstmt1,"SELECT * FROM Orders",SQL_NTS))==SQL_STILL_EXECUTING) {  
   // While the statement is still executing, do something else.  
   // like get CALLBACK from DF program 
}  
  
// When the statement has finished executing, retrieve the results.
If the executing statement could provide a CALLBACK function, then:


  1. Long executing statements will not cause the DF program to go into a "not responding" mode.
  2. As documented, if the Callback function returns TRUE, then the SQLExec/SQLExecDirect operation could be cancelled via the SQLCancel method.


A classic example would be, if you were to restructure a large table within the Studio (ie, adding/modifying a column) - the entire studio goes into a "not responding" state and Windows may ask you to close the program if you accidentally click on it.

If the above could be done, then there would almost be no change in the DataFlex layer - except probably a new property within the cSQLStatement class called "Handle phoCallBackObj"

Food for thought
+1