About extended stored procedures

Hi,
I have such situation:
A function that make some custom translation of numbers (convert numbers to
text). I have this function in DLL. I want to use that function in my
selects like that:
SELECT SOME_NUMBER, xp_transfunc(SOME_NUMBER) AS SOME_NUMBER_AS_TEXT
FROM SOME_TABLE
What are my options? Extended stored procedure? Something else? I know that
Extended stored procedures are function in external DLL that meet some
requirements, but can I use Extended stored procedure in such way?
TIA,
Miro.Hi Miro.
You can't call an xp_ directly in a set based call like that.
To do a set based call against an external library, you'd wrap the library
in a udf(), but calls to the xp_ will be serialized so performance might not
be too thrilling, depending on the number of rows in the select & the amount
of work / efficiency of the xp_.
If the custom logic isn't too complex, you might consider consider
converting to a t-sql udf() as this would give you the best performance, if
that's important to you..
HTH
Regards,
Greg Linwood
SQL Server MVP
"Miro Penchev" <miroslav.penchev@.bsc.bg> wrote in message
news:opr1pl4riy12pphn@.msnews.microsoft.com...
> Hi,
> I have such situation:
> A function that make some custom translation of numbers (convert numbers
to
> text). I have this function in DLL. I want to use that function in my
> selects like that:
> SELECT SOME_NUMBER, xp_transfunc(SOME_NUMBER) AS SOME_NUMBER_AS_TEXT
> FROM SOME_TABLE
> What are my options? Extended stored procedure? Something else? I know
that
> Extended stored procedures are function in external DLL that meet some
> requirements, but can I use Extended stored procedure in such way?
> TIA,
> Miro.|||There are only extended stored procedures and you would need to use EXEC to
call them. This sort of syntax is currently not supported for extended
stored procedures. Even if you call extended stored procedures from
functions, you have many restrictions there.
--
HTH,
SriSamp
Please reply to the whole group only!
http://www32.brinkster.com/srisamp
"Miro Penchev" <miroslav.penchev@.bsc.bg> wrote in message
news:opr1pl4riy12pphn@.msnews.microsoft.com...
> Hi,
> I have such situation:
> A function that make some custom translation of numbers (convert numbers
to
> text). I have this function in DLL. I want to use that function in my
> selects like that:
> SELECT SOME_NUMBER, xp_transfunc(SOME_NUMBER) AS SOME_NUMBER_AS_TEXT
> FROM SOME_TABLE
> What are my options? Extended stored procedure? Something else? I know
that
> Extended stored procedures are function in external DLL that meet some
> requirements, but can I use Extended stored procedure in such way?
> TIA,
> Miro.|||For now you should use a UDF. When YUKON comes out, you can make your UDF in
ainy dot net language... today your UDF must be written in T-SQL...
Another thing you might consider is writing a com object then using
sp_oacreate in a function to invoke it, but performance ( I suspect) would
not be as good as if you had written the UDF directly ONLY using T-SQL
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Miro Penchev" <miroslav.penchev@.bsc.bg> wrote in message
news:opr1pl4riy12pphn@.msnews.microsoft.com...
> Hi,
> I have such situation:
> A function that make some custom translation of numbers (convert numbers
to
> text). I have this function in DLL. I want to use that function in my
> selects like that:
> SELECT SOME_NUMBER, xp_transfunc(SOME_NUMBER) AS SOME_NUMBER_AS_TEXT
> FROM SOME_TABLE
> What are my options? Extended stored procedure? Something else? I know
that
> Extended stored procedures are function in external DLL that meet some
> requirements, but can I use Extended stored procedure in such way?
> TIA,
> Miro.|||On Tue, 13 Jan 2004 21:55:34 +1100
"Greg Linwood" <g_linwoodQhotmail.com> wrote:
> Hi Miro.
> You can't call an xp_ directly in a set based call like that.
> To do a set based call against an external library, you'd wrap the library
> in a udf(), but calls to the xp_ will be serialized so performance might not
> be too thrilling, depending on the number of rows in the select & the amount
> of work / efficiency of the xp_.
> If the custom logic isn't too complex, you might consider consider
> converting to a t-sql udf() as this would give you the best performance, if
> that's important to you..
The performance is not important in my case because that function will be used in SELECTs with small number of rows in result set (in most cases with only one row in result set). And the logic is complex enough to have that logic in two sources - one in SQL and one in my source. So I will made it with xp_.
Thanks again for your help,
Miro.|||On Tue, 13 Jan 2004 06:24:04 -0500
"Wayne Snyder" <wsnyder@.computeredservices.com> wrote:
> For now you should use a UDF. When YUKON comes out, you can make your UDF in
> ainy dot net language...
:) Ooo god - no! The 'dot net' is the BIG mistake in world of programming for last 20 years ;).
> today your UDF must be written in T-SQL...
> Another thing you might consider is writing a com object then using
> sp_oacreate in a function to invoke it, but performance ( I suspect) would
> not be as good as if you had written the UDF directly ONLY using T-SQL
I prefer to do it in xp_ and make wrapper for it in UDF (see my other post in that thread). Logic inside is too complex to have two sources to maintain - one in T_SQL and one in my source (Delphi source actually).
10x,
Miro.