|
Can EXTERNAL NAME 'native-call' and EXTERNAL NAME 'c-call' LANGUAGE ... definitions be mixed for two different functions in the same DLL? What about mixing LANGUAGE { C_ESQL32 | C_ESQL64 | C_ODBC32 | C_ODBC64 } definitions for different functions in the same DLL? Or, should the different functions be in different DLLs? I am guessing the answers are "no, no, yes" but the Help for the CREATE PROCEDURE statement (external procedures) doesn't appear to cover this possibility. CREATE [ OR REPLACE ] PROCEDURE [ owner.]procedure-name
...
{ EXTERNAL NAME 'native-call'
| EXTERNAL NAME 'c-call' LANGUAGE { C_ESQL32 | C_ESQL64 | C_ODBC32 | C_ODBC64 }
... }
|
|
The answer is no, no, maybe. Having both an external name '...' and an external name '...' language ... is ambiguous. When you execute that procedure/function, what are you expecting the server to do? Should it load the dll in-process or should it launch the external environment? So no, you cannot mix the two for two different functions in the same dll. As for mixing language And as Volker already pointed out, having both 32-bit and 64-bit code in the same C/C++ dll does not make sense. Having mixed mode CLR assemblies is perfectly valid but the CLR external environment is not being discussed here. However, as Volker also indicates, multiple processes can load the same dll so you are not required to have different functions in different DLLs unless you are mixing bitnesses or ESQL and ODBC. Hence the answer is no, no, maybe. I will discuss the lack of clarity of the documentation with the doc team and see if we can get the doc issue resolved. Karim, you statement on ambiguity seems to relate to only one function (if my understanding is correct). For two different functions I'd expect the server
Therefore I had guessed that in a similar way calling two different functions (one with C_ESQL, one with C_ODBC) from the same DLL would just start two external environments, one using dblib, one ODBC, and each process loading the DLL... The background for my guessing is the fact that DLLs can be loaded into several processes. Note: That's just my "Technically, it might work" point of view - if the implementation is different or there are other pitfalls, then my point is surely moot:)
(16 Jan '13, 04:02)
Volker Barth
Volker, you are correct in your observation but there currently is no way to distinguish which function is which in the external name clause. If/when the external name clause is expanded to allow such differentiation, then yes, it will make sense to have one wrapper for both in-process and multiple external environment functions.
(16 Jan '13, 08:54)
Karim Khamis
Replies hidden
Hm, is that not distinguishable here? -- native call CREATE FUNCTION mystring1(IN instr LONG VARCHAR) RETURNS LONG VARCHAR EXTERNAL NAME 'mystring1@mylib'; -- call with external environment CREATE FUNCTION mystring2(IN instr LONG VARCHAR) RETURNS LONG VARCHAR EXTERNAL NAME 'mystring2@mylib' LANGUAGE C_ODBC32;
(16 Jan '13, 09:11)
Volker Barth
I think Volker is asking the following question; if not, then I am: What exactly do you mean by "there currently is no way to distinguish which function is which in the external name clause"?
(16 Jan '13, 09:16)
Breck Carter
I think you think correctly of what I am thinking:) Aside: I hope the usage of an adverb is correct here... LANGUAGE ENGLISH is a non-native call in my case:)
(16 Jan '13, 09:59)
Volker Barth
No problem... LANGUAGE YODA I speak :)
(16 Jan '13, 16:20)
Breck Carter
|
As DLLs can be loaded by different processes at the same time, I guess (but don't know) the answers could be "yes", "yes", "no, but I would recommend that"...
I'm even less sure whether ESQL and ODBC can be mixed (and what would this be good for), and it should be difficult to have a C DLL loaded by both 32-bit and 64-bit processes...
Wild-guessing, you see:)