SQL Anywhere has had the ability to call compiled native functions written in C or C++ for some time. However, when these procedures are run by the database server, the dynamic link library or shared object has always been loaded by the database server and the calls out to the native functions have always been made by the database server. While having the database server make these native calls is most efficient, there can be serious consequences if the native function misbehaves. In particular, if the native function enters an infinite loop, then the database server can hang, and if the native function causes a fault, then the database server crashes. As a result, you now have the option of running compiled native functions outside the database server, in an external environment. There are some key benefits to running a compiled native function in an external environment:
The database server does not hang or crash if the compiled native function misbehaves.
The native function can be written to use ODBC, Embedded SQL (ESQL), or the SQL Anywhere C API and can make server-side calls back into the database server without having to make a connection.
The native function can return a result set to the database server.
In the external environment, a 32-bit database server can communicate with a 64-bit compiled native function and vice versa. Note that this is not possible when the compiled native functions are loaded directly into the address space of the database server. A 32-bit library can only be loaded by a 32-bit server and a 64-bit library can only be loaded by a 64-bit server.
Running a compiled native function in an external environment instead of within the database server results in a small performance penalty.
Also, the compiled native function must use the native function call interface to pass information to and return information from the native function. This interface is described in SQL Anywhere external call interface.
To run a compiled native C function in an external environment instead of within the database server, the stored procedure or function is defined with the EXTERNAL NAME clause followed by the LANGUAGE attribute specifying one of C_ESQL32, C_ESQL64, C_ODBC32, or C_ODBC64.
Unlike the Perl, PHP, and Java external environments, you do not install any source code or compiled objects in the database. As a result, you do not need to execute any INSTALL statements before using the ESQL and ODBC external environments.
Here is an example of a function written in C++ that can be run within the database server or in an external environment.
#include <windows.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include "extfnapi.h" BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { return TRUE; } // Note: extfn_use_new_api used only for // execution in the database server extern "C" __declspec( dllexport ) a_sql_uint32 extfn_use_new_api( void ) { return( EXTFN_API_VERSION ); } extern "C" __declspec( dllexport ) void SimpleCFunction( an_extfn_api *api, void *arg_handle ) { short result; an_extfn_value arg; an_extfn_value retval; int * intptr; int i, j, k; j = 1000; k = 0; for( i = 1; i <= 4; i++ ) { result = api->get_value( arg_handle, i, &arg ); if( result == 0 || arg.data == NULL ) break; if( arg.type & DT_TYPES != DT_INT ) break; intptr = (int *) arg.data; k += *intptr * j; j = j / 10; } retval.type = DT_INT; retval.data = (void*)&k; retval.piece_len = retval.len.total_len = (a_sql_uint32) sizeof( int ); api->set_value( arg_handle, 0, &retval, 0 ); return; } |
When compiled into a dynamic link library or shared object, this function can be called from an external environment. An executable image called dbexternc12 is started by the database server and this executable image loads the dynamic link library or shared object for you. Different versions of this executable are included with SQL Anywhere. For example, on Windows you may have both 32-bit and 64-bit executables.
Note that 32-bit or 64-bit versions of the database server can be used and either version can start 32-bit or 64-bit versions of dbexternc12. This is one of the advantages of using the external environment. Note that once dbexternc12 is started by the database server, it does not terminate until the connection has been terminated or a STOP EXTERNAL ENVIRONMENT statement (with the correct environment name) is executed. Each connection that does an external environment call will get its own copy of dbexternc12.
To call the compiled native function, SimpleCFunction, a wrapper is defined as follows:
CREATE FUNCTION SimpleCDemo( IN arg1 INT, IN arg2 INT, IN arg3 INT, IN arg4 INT ) RETURNS INT EXTERNAL NAME 'SimpleCFunction@c:\\c\\extdemo.dll' LANGUAGE C_ODBC32; |
This is almost identical to the way a compiled native function is described when it is to be loaded into the database server's address space. The one difference is the use of the LANGUAGE C_ODBC32 clause. This clause indicates that SimpleCDemo is a function running in an external environment and that it is using 32-bit ODBC calls. The language specification of C_ESQL32, C_ESQL64, C_ODBC32, or C_ODBC64 tells the database server whether the external C function issues 32-bit or 64-bit ODBC, ESQL, or SQL Anywhere C API calls when making server-side requests.
When the native function uses none of the ODBC, ESQL, or SQL Anywhere C API calls to make server-side requests, then either C_ODBC32 or C_ESQL32 can be used for 32-bit applications and either C_ODBC64 or C_ESQL64 can be used for 64-bit applications. This is the case in the external C function shown above. It does not use any of these APIs.
To execute the sample compiled native function, execute the following statement.
SELECT SimpleCDemo(1,2,3,4); |
To use server-side ODBC, the C/C++ code must use the default database connection. To get a handle to the database connection, call get_value with an EXTFN_CONNECTION_HANDLE_ARG_NUM argument. The argument tells the database server to return the current external environment connection rather than opening a new one.
#include <windows.h> #include <stdio.h> #include "odbc.h" #include "extfnapi.h" BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { return TRUE; } extern "C" __declspec( dllexport ) void ServerSideFunction( an_extfn_api *api, void *arg_handle ) { short result; an_extfn_value arg; an_extfn_value retval; SQLRETURN ret; ret = -1; // set up the return value struct retval.type = DT_INT; retval.data = (void*) &ret; retval.piece_len = retval.len.total_len = (a_sql_uint32) sizeof( int ); result = api->get_value( arg_handle, EXTFN_CONNECTION_HANDLE_ARG_NUM, &arg ); if( result == 0 || arg.data == NULL ) { api->set_value( arg_handle, 0, &retval, 0 ); return; } HDBC dbc = (HDBC)arg.data; HSTMT stmt = SQL_NULL_HSTMT; ret = SQLAllocHandle( SQL_HANDLE_STMT, dbc, &stmt ); if( ret != SQL_SUCCESS ) return; ret = SQLExecDirect( stmt, (SQLCHAR *) "INSERT INTO odbcTab " "SELECT table_id, table_name " "FROM SYS.SYSTAB", SQL_NTS ); if( ret == SQL_SUCCESS ) { SQLExecDirect( stmt, (SQLCHAR *) "COMMIT", SQL_NTS ); } SQLFreeHandle( SQL_HANDLE_STMT, stmt ); api->set_value( arg_handle, 0, &retval, 0 ); return; } |
If the above ODBC code is stored in the file extodbc.cpp, it can be built for Windows using the following commands (assuming that the SQL Anywhere software is installed in the folder c:\sa12 and that Microsoft Visual C++ is installed).
cl extodbc.cpp /LD /Ic:\sa12\sdk\include odbc32.lib |
The following example creates a table, defines the stored procedure wrapper to call the compiled native function, and then calls the native function to populate the table.
CREATE TABLE odbcTab(c1 int, c2 char(128)); CREATE FUNCTION ServerSideODBC( ) RETURNS INT EXTERNAL NAME 'ServerSideFunction@extodbc.dll' LANGUAGE C_ODBC32; SELECT ServerSideODBC(); // The following statement should return two identical rows SELECT COUNT(*) FROM odbcTab UNION ALL SELECT COUNT(*) FROM SYS.SYSTAB; |
Similarly, to use server-side ESQL, the C/C++ code must use the default database connection. To get a handle to the database connection, call get_value with an EXTFN_CONNECTION_HANDLE_ARG_NUM argument. The argument tells the database server to return the current external environment connection rather than opening a new one.
#include <windows.h> #include <stdio.h> #include "sqlca.h" #include "sqlda.h" #include "extfnapi.h" BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { return TRUE; } EXEC SQL INCLUDE SQLCA; static SQLCA *_sqlc; EXEC SQL SET SQLCA "_sqlc"; EXEC SQL WHENEVER SQLERROR { ret = _sqlc->sqlcode; }; extern "C" __declspec( dllexport ) void ServerSideFunction( an_extfn_api *api, void *arg_handle ) { short result; an_extfn_value arg; an_extfn_value retval; EXEC SQL BEGIN DECLARE SECTION; char *stmt_text = "INSERT INTO esqlTab " "SELECT table_id, table_name " "FROM SYS.SYSTAB"; char *stmt_commit = "COMMIT"; EXEC SQL END DECLARE SECTION; int ret = -1; // set up the return value struct retval.type = DT_INT; retval.data = (void*) &ret; retval.piece_len = retval.len.total_len = (a_sql_uint32) sizeof( int ); result = api->get_value( arg_handle, EXTFN_CONNECTION_HANDLE_ARG_NUM, &arg ); if( result == 0 || arg.data == NULL ) { api->set_value( arg_handle, 0, &retval, 0 ); return; } ret = 0; _sqlc = (SQLCA *)arg.data; EXEC SQL EXECUTE IMMEDIATE :stmt_text; EXEC SQL EXECUTE IMMEDIATE :stmt_commit; api->set_value( arg_handle, 0, &retval, 0 ); } |
If the above embedded SQL statements are stored in the file extesql.sqc, it can be built for Windows using the following commands (assuming that the SQL Anywhere software is installed in the folder c:\sa12 and that Microsoft Visual C++ is installed).
sqlpp extesql.sqc extesql.cpp cl extesql.cpp /LD /Ic:\sa12\sdk\include c:\sa12\sdk\lib\x86\dblibtm.lib |
The following example creates a table, defines the stored procedure wrapper to call the compiled native function, and then calls the native function to populate the table.
CREATE TABLE esqlTab(c1 int, c2 char(128)); CREATE FUNCTION ServerSideESQL( ) RETURNS INT EXTERNAL NAME 'ServerSideFunction@extesql.dll' LANGUAGE C_ESQL32; SELECT ServerSideESQL(); // The following statement should return two identical rows SELECT COUNT(*) FROM esqlTab UNION ALL SELECT COUNT(*) FROM SYS.SYSTAB; |
As in the previous examples, to use server-side SQL Anywhere C API calls, the C/C++ code must use the default database connection. To get a handle to the database connection, call get_value with an EXTFN_CONNECTION_HANDLE_ARG_NUM argument. The argument tells the database server to return the current external environment connection rather than opening a new one. The following example shows the framework for obtaining the connection handle, initializing the C API environment, and transforming the connection handle into a connection object (a_sqlany_connection) that can be used with the SQL Anywhere C API.
#include <windows.h> #include "sacapidll.h" #include "extfnapi.h" BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { return TRUE; } extern "C" __declspec( dllexport ) void ServerSideFunction( an_extfn_api *extapi, void *arg_handle ) { short result; an_extfn_value arg; an_extfn_value retval; unsigned offset; char *cmd; SQLAnywhereInterface capi; a_sqlany_connection * sqlany_conn; unsigned int max_api_ver; result = extapi->get_value( arg_handle, EXTFN_CONNECTION_HANDLE_ARG_NUM, &arg ); if( result == 0 || arg.data == NULL ) { return; } if( !sqlany_initialize_interface( &capi, NULL ) ) { return; } if( !capi.sqlany_init( "MyApp", SQLANY_CURRENT_API_VERSION, &max_api_ver ) ) { sqlany_finalize_interface( &capi ); return; } sqlany_conn = sqlany_make_connection( arg.data ); // processing code goes here capi.sqlany_fini(); sqlany_finalize_interface( &capi ); return; } |
If the above C code is stored in the file extcapi.c, it can be built for Windows using the following commands (assuming that the SQL Anywhere software is installed in the folder c:\sa12 and that Microsoft Visual C++ is installed).
cl /LD /Tp extcapi.c /Tp c:\sa12\SDK\C\sacapidll.c /Ic:\sa12\SDK\Include c:\sa12\SDK\Lib\X86\dbcapi.lib |
The following example defines the stored procedure wrapper to call the compiled native function, and then calls the native function.
CREATE FUNCTION ServerSideC() RETURNS INT EXTERNAL NAME 'ServerSideFunction@extcapi.dll' LANGUAGE C_ESQL32; SELECT ServerSideC(); |
The LANGUAGE attribute in the above example specifies C_ESQL32. For 64-bit applications, you would use C_ESQL64. You must use the embedded SQL language attribute since the SQL Anywhere C API is built on the same layer (library) as ESQL.
As mentioned earlier, each connection that does an external environment call will start its own copy of dbexternc12. This executable application is loaded automatically by the server the first time an external environment call is made. However, you can use the START EXTERNAL ENVIRONMENT statement to preload dbexternc12. This is useful if you want to avoid the slight delay that is incurred when an external environment call is executed for the first time. Here is an example of the statement.
START EXTERNAL ENVIRONMENT C_ESQL32 |
Another case where preloading dbexternc12 is useful is when you want to debug your external function. You can use the debugger to attach to the running dbexternc12 process and set breakpoints in your external function.
The STOP EXTERNAL ENVIRONMENT statement is useful when updating a dynamic link library or shared object. It will terminate the native library loader, dbexternc12, for the current connection thereby releasing access to the dynamic link library or shared object. If multiple connections are using the same dynamic link library or shared object then each of their copies of dbexternc12 must be terminated. The appropriate external environment name must be specified in the STOP EXTERNAL ENVIRONMENT statement. Here is an example of the statement.
STOP EXTERNAL ENVIRONMENT C_ESQL32 |
To return a result set from an external function, the compiled native function must use the native function call interface. This interface is fully described in SQL Anywhere external call interface. The following are some of the highlights for returning result sets.
The following code fragment shows how to set up a result set information structure. It contains a column count, a pointer to an array of column information structures, and a pointer to an array of column data value structures. The example also uses the SQL Anywhere C API.
an_extfn_result_set_info rs_info; int columns = capi.sqlany_num_cols( sqlany_stmt ); an_extfn_result_set_column_info *col_info = (an_extfn_result_set_column_info *) malloc( columns * sizeof(an_extfn_result_set_column_info) ); an_extfn_result_set_column_data *col_data = (an_extfn_result_set_column_data *) malloc( columns * sizeof(an_extfn_result_set_column_data) ); rs_info.number_of_columns = columns; rs_info.column_infos = col_info; rs_info.column_data_values = col_data; |
The following code fragment shows how to describe the result set. It uses the SQL Anywhere C API to obtain column information for a SQL query that was executed previously by the C API. The information that is obtained from the SQL Anywhere C API for each column is transformed into a column name, type, width, index, and null value indicator that will be used to describe the result set.
a_sqlany_column_info info; for( int i = 0; i < columns; i++ ) { if( sqlany_get_column_info( sqlany_stmt, i, &info ) ) { // set up a column description col_info[i].column_name = info.name; col_info[i].column_type = info.native_type; switch( info.native_type ) { case DT_DATE: // DATE is converted to string by C API case DT_TIME: // TIME is converted to string by C API case DT_TIMESTAMP: // TIMESTAMP is converted to string by C API case DT_DECIMAL: // DECIMAL is converted to string by C API col_info[i].column_type = DT_FIXCHAR; break; case DT_FLOAT: // FLOAT is converted to double by C API col_info[i].column_type = DT_DOUBLE; break; case DT_BIT: // BIT is converted to tinyint by C API col_info[i].column_type = DT_TINYINT; break; } col_info[i].column_width = info.max_size; col_info[i].column_index = i + 1; // column indices are origin 1 col_info[i].column_can_be_null = info.nullable; } } // send the result set description if( extapi->set_value( arg_handle, EXTFN_RESULT_SET_ARG_NUM, (an_extfn_value *)&rs_info, EXTFN_RESULT_SET_DESCRIBE ) == 0 ) { // failed free( col_info ); free( col_data ); return; } |
Once the result set has been described, the result set rows can be returned. The following code fragment shows how to return the rows of the result set. It uses the SQL Anywhere C API to fetch the rows for a SQL query that was executed previously by the C API. The rows returned by the SQL Anywhere C API are sent back, one at a time, to the calling environment. The array of column data value structures must be filled in before returning each row. The column data value structure consists of a column index, a pointer to a data value, a data length, and an append flag.
a_sqlany_data_value *value = (a_sqlany_data_value *) malloc( columns * sizeof(a_sqlany_data_value) ); while( capi.sqlany_fetch_next( sqlany_stmt ) ) { for( int i = 0; i < columns; i++ ) { if( capi.sqlany_get_column( sqlany_stmt, i, &value[i] ) ) { col_data[i].column_index = i + 1; col_data[i].column_data = value[i].buffer; col_data[i].data_length = (a_sql_uint32)*(value[i].length); col_data[i].append = 0; if( *(value[i].is_null) ) { // Received a NULL value col_data[i].column_data = NULL; } } } if( extapi->set_value( arg_handle, EXTFN_RESULT_SET_ARG_NUM, (an_extfn_value *)&rs_info, EXTFN_RESULT_SET_NEW_ROW_FLUSH ) == 0 ) { // failed free( value ); free( col_data ); free( col_data ); extapi->set_value( arg_handle, 0, &retval, 0 ); return; } } |
For additional information, see SQL Anywhere external call interface.
For more information on how to make server-side requests and how to return result sets from an external function, refer to the samples in samples-dir\SQLAnywhere\ExternalEnvironments\ExternC.
Discuss this page in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |