I'm testing the C external environments in SQL Anywhere 220.127.116.112.
When I have an external C function (with the "new external API") that runs fine in the context of the server, I expect that function behaves (nearly) identical when run in the 32-bit ESQL or ODBC environments. (There are no database calls at all in the external DLL so that aspect shouldn't matter.)
As I understand there are four main differences between calls in the engine's context ("internal") and in the external C environments:
In my test case, only the 2nd point should make a (minor) difference, but the external function behaves differently when run internally vs. externally.
Question: Are there more differences to take care of?
EDITED: According to Karim's answer, the following difference is a bug and is fixed in coming versions. Obviously, it's not a difference by design - in contrast to to ones listed in my question.
Well, at the moment I notice a difference when using optional parameters:
Say, I have an external function declared as
Inside the C function, I use the following code to get the value of the 2nd parameter (quite unchanged from the ASA 8 "ExternalProcedures" sample):
When I call that function and set the 2nd paramter to its default value as in
then the internal call returns a non-zero value as success and shows the arg2.data value correctly as null, whereas the C_ODBC32 environment returns 0 meaning failure.
When the parameter has a not-null value, both environments behave correctly.
Tested with SA 18.104.22.1687, I guess SA 22.214.171.1242 and 126.96.36.1999 behave identically.
Let's assume you are using the C_ESQL32 environment and your dll is mystuff.dll. Try the following:
1) start external environment c_esql32 // this should get the executable launched 2) attach your debugger to the dbexternc11.exe process 3) create a procedure that loads your dll but maps to a function that does not exist
CREATE PROCEDURE junk() EXTERNAL NAME 'email@example.com' LANGUAGE C_ESQL32
4) call junk() // this will return with an error saying that notexist does not exist, BUT, your dll should now be loaded
5) go back to the debugger and set the appropriate break points
6) make the call that gets you to your breakpoint
See if that does the trick as far as getting the debugger going.
answered 30 Jun '10, 17:33
Thank you for narrowing this problem down and for reporting the bug. The external C environment(s) have been fixed to ensure that a status of 1 is returned when get_value() is called on a NULL argument. The fix will be available in 11.0.1 build 2460 and up. Note that for 12.0.0, the fix will not be available until the first 12.0.0 EBF
answered 05 Jul '10, 19:11