The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

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 }
... }

asked 08 Jan '13, 09:27

Breck%20Carter's gravatar image

Breck Carter
26.6k418576824
accept rate: 21%

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

(08 Jan '13, 10:05) Volker Barth

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 C_ESQL and C_ODBC, that also is not allowed. If you choose C_ESQL, then the external environment connects using dblib and passes that dblib connection down to the user code for making ESQL server-side requests. Similarly, if you choose C_ODBC, then the external environment connects using ODBC and that ODBC connection handle is instead passed down to the user code for making server-side requests. The environment will not make both a dblib and ODBC connection so mixing C_ESQL with C_ODBC is disallowed.

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.

permanent link

answered 15 Jan '13, 14:38

Karim%20Khamis's gravatar image

Karim Khamis
5.6k53870
accept rate: 40%

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

  • to load the DLL in-process for a function declared with a native-call (i.e. no LANGUAGE clause) and
  • to load the DLL into the external environment for a function declared with a LANGUAGE clause.

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
showing 2 of 6 show all flat view
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×101

question asked: 08 Jan '13, 09:27

question was seen: 615 times

last updated: 16 Jan '13, 16:21