SAP SQL Anywhere

Question

I'm testing the C external environments in SQL Anywhere 11.0.1.2452.

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:

Internally called DLLs must match w.r.t. bit-ness (32 vs. 64), externally called DLLs can vary.
Each internally loaded DLL is loaded once per database engine, whereas each connection gets its own external C environment.
As a consequence, internally loaded DLLs can crash the database engine, corrupt memory and the like, an externally loaded DLL can do such harm only to its isolated process.
Internal calls are more efficient because there's no interprocess communication and no starting/stopping overhead for the external process.

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?

Accepted Answer

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

create function FKTN_LockMutex(
   strMutexName varchar(255), nMillisecondsTimeout unsigned int default null)
   returns int
   external name 'LockMutex@MyDll';

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):

bReturn = api->get_value(arg_handle, 2, &arg2);

When I call that function and set the 2nd paramter to its default value as in

select FKTN_LockMutex('MtxTest');

or

select FKTN_LockMutex('MtxTest', null);

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 11.0.1.2427, I guess SA 11.0.1.2452 and 12.0.0.2429 behave identically.

Answer 2

2

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 'notexist@mystuff.dll' 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.

permanent link

answered 30 Jun '10, 17:33

Karim Khamis
5.7k●5●38●70
accept rate: 40%

I just tried that (with C_ODBC32), and I still have the problem that the command "Debug/Attach to process" opens a new project with only the dbexternc.exe, and my original DLL project is closed. As such I don't get any debug output nor am I able to set breakpoints and the like. I have assured per ProcExp that dbexternc.exe has loaded the correct DLL but the debugger doesn't seem to notice that I want to use the attached process to debug my DLL:)

(01 Jul '10, 13:08) Volker Barth

Well, I had tested with VC++ 6 so far (as this is the IDE on the according test system) and have now converted the project to VS 2005. Now I can attach my DLL project to a running process and look what's different. - Is that a known VC++ 6 limitation?

(01 Jul '10, 13:43) Volker Barth

flat view

Answer 3

1

Volker,

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

permanent link

answered 05 Jul '10, 19:11

Karim Khamis
5.7k●5●38●70
accept rate: 40%

flat view

SAP SQL Anywhere

What's the difference between calling a simple C function in the servers' context and in the external environments?

Follow this question

Related questions