Extended Stored Procedures DB-Lib Alternative

Since DBlib is no longer the suggested method for connecting back to
sql server from an Extended Stored Procedure, has anyone built any
extended stored procedures that use other connection methods like
OLEDB? Has anyone seen links to any sample extended stored procedures
that use something other than db-lib? In particular I am interested
in something that connects back to the database as the user who
invoked the extended stored procedure. I haven't had much luck
finding any.

Also, is there an alternative for the bcp api that is a little more
current and has support for newer datatypes like bigint? We currently
use the bcp api from an extended stored procdure written in C++, but
now need to add bigint support which the bcp api doesn't have.

Thanks for any advice.You can use ODBC or OLEDB, I prefer ODBC because it is lean and mean and I
do not like COM. Both support the full set of data types including BIGINT.

ODBC contains an updated version of the BCP API since SQL Server 7.0 which
also supports all new data types or alternatively you can use the
IRowsetFastload interface if you want to use OLE DB.

There ships an ODBC sample with SQL Server, see "C:\Program Files\Microsoft
SQL Server\80\Tools\DevTools\Samples\ods\xp_odbc", there is no OLE-DB
sample.

GertD@.SQLDev.Net

Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.

"Bruce" <sandell@.pacbell.net> wrote in message
news:595024a5.0409171238.10aed173@.posting.google.c om...
> Since DBlib is no longer the suggested method for connecting back to
> sql server from an Extended Stored Procedure, has anyone built any
> extended stored procedures that use other connection methods like
> OLEDB? Has anyone seen links to any sample extended stored procedures
> that use something other than db-lib? In particular I am interested
> in something that connects back to the database as the user who
> invoked the extended stored procedure. I haven't had much luck
> finding any.
> Also, is there an alternative for the bcp api that is a little more
> current and has support for newer datatypes like bigint? We currently
> use the bcp api from an extended stored procdure written in C++, but
> now need to add bigint support which the bcp api doesn't have.
> Thanks for any advice.|||> Since DBlib is no longer the suggested method for connecting back to
> sql server from an Extended Stored Procedure, has anyone built any
> extended stored procedures that use other connection methods like
> OLEDB? Has anyone seen links to any sample extended stored procedures
> that use something other than db-lib? In particular I am interested

ODBC Connection works fine for the loopback in ESP's. Sample
application for the same is provided in the SQL Server Samples|||Thanks very much for the advice. I'll take a look into bcp for odbc.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Expressions in queries

I'm new to SQL Server and converting a VB app from Access back end to
SQL Server back end. In this app I use a lot of expressions in
queries
e.g. SELECT iif(isnull([MyText],"",[MyText]) as sRemoveNull
or SELECT [SaleDate]>=#01-Jan-2004# as bUseSale
I can't get anything of the sort to work in SQL Server. I've written a
few UDFs to cope with some more common expressions, but for some cases
it would be much easier to be able to use a complex expression within
the query.
Stored Procedures are not really appropriate as queries are built in
VB and the SQL string passed to SQL Server.
Am I missing something obvious?
Thanks,
MattThese two examples may help. You can check out the full syntax of these
expressions in SQL Server Books Online.
SELECT COALESCE(mytext,'') AS sRemoveNull
SELECT CASE WHEN saledate>='20040101' THEN 1 ELSE 0 END AS bUseSale

> queries are built in
> VB and the SQL string passed to SQL Server.
In the world of SQL Server that's generally a really bad idea. Standard
practice is to use SPs for all data access unless you have an exceptional
reason not to. SPs make the most sense from the point of view of
performance, security and maintainability. If you just want to continue
using SQL the way you've always used Access then you can't expect to realize
all the benefits of the platform change. You may well be better off sticking
with your Access backend.
David Portas
SQL Server MVP
--|||Thanks David, that'll get me started.
Re your further comments, I was also going to post the
"How do I do SELECT * FROM @.tablename" question last night,
but did some reading here first and found numerous responses along the
same lines as yours. I've read two articles from www.sommarskog.se
about dynamic SQL and it seems I have to accept that I'll have to do
things quite differently in the future than I have been (sticking with
Access is not an option). The upside is that I'm learning heaps and
enjoying doing it.
Thanks for your comments.
Matt
On Sun, 30 Jan 2005 18:03:56 -0000, "David Portas"
<REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote:

>These two examples may help. You can check out the full syntax of these
>expressions in SQL Server Books Online.
>SELECT COALESCE(mytext,'') AS sRemoveNull
>SELECT CASE WHEN saledate>='20040101' THEN 1 ELSE 0 END AS bUseSale
>
>In the world of SQL Server that's generally a really bad idea. Standard
>practice is to use SPs for all data access unless you have an exceptional
>reason not to. SPs make the most sense from the point of view of
>performance, security and maintainability. If you just want to continue
>using SQL the way you've always used Access then you can't expect to realiz
e
>all the benefits of the platform change. You may well be better off stickin
g
>with your Access backend.
>--
>David Portas
>SQL Server MVP