Question 1: Is the EXTERNAL NAME clause with no LANGUAGE attribute bound at compile time (when the CREATE PROCEDURE is executed) or is it bound at run time (when the procedure is called or the DLL is loaded)? The answer appears to be "run time" although that doesn't seem to be mentioned in the Help. Question 2: Is it possible to specify separate DLL names for Windows 32-bit and Windows 64-bit in the same EXTERNAL NAME clause? E.g., CREATE PROCEDURE mystring( IN instr LONG VARCHAR ) EXTERNAL NAME 'Win32:mystring@mylib32.dll;Win64:mystring@mylib64.dll'; I am trying to make a database easily portable between the two platforms, by simply providing both DLLs and letting SQL code pick which one it wants at runtime. Here is an excerpt from the Help: CREATE PROCEDURE statement External call ===== EXTERNAL NAME clause A procedure using the EXTERNAL NAME clause with no LANGUAGE attribute defines an interface to a native function written in a programming language such as C. The native function is loaded by the database server into its address space. The library name can include the file extension, which is typically .dll on Windows and .so on Unix. In the absence of the extension, the software appends the platform-specific default file extension for libraries. The following is a formal example. CREATE PROCEDURE mystring( IN instr LONG VARCHAR ) EXTERNAL NAME 'mystring@mylib.dll;Unix:mystring@mylib.so'; A simpler way to write the above EXTERNAL NAME clause, using platform-specific defaults, is as follows: CREATE PROCEDURE mystring( IN instr LONG VARCHAR ) EXTERNAL NAME 'mystring@mylib'; When called, the library containing the function is loaded into the address space of the database server. The native function will execute as part of the server. In this case, if the function causes a fault, then the database server will be terminated. Because of this, loading and executing functions in an external environment using the LANGUAGE attribute is recommended. If a function causes a fault in an external environment, the database server will continue to run. For syntaxes that support operating-system, if you do not specify operating-system, then it is assumed that the procedure runs on all platforms. If you specify Unix for one of the calls, then it is assumed that the other call is for Windows. ===== |
1) You are correct, it is at run time once the dll is loaded. 2) No, there currently is no way to specify both a 32-bit and 64-bit dll in the same external name clause. Your best bet is to have two external functions (one for 32-bit and one for 64-bit) and then have an extra SQL stored function that determines the appropriate bitness and calls the correct external function. Re #2: sounds like an enhancement is required! - I've added it to the list.
(18 Dec '12, 10:32)
Mark Culp
|
Based on Karim's answer, a simple workaround would be to
That way, you shound not need to change/wrap the external procedure calls within your code. |