Call stored procedure from activex dll

[Luis]

I'm using code similar to the following in an asp page to call a
stored procedure that does a select on a SQLServer 2000 table:

dim rs, SelectSql
SelectSql = "EXEC spSelectStuff @param = '" & ParamValue & "'"
set rs = conn.Execute(SelectSql)
-- do some stuff with rs --
rs.close : set rs = nothing...


The SelectStuff procedure:
CREATE PROCEDURE dbo.spSelectStuff
@param INT
AS

BEGIN
SET NOCOUNT ON
SELECT colX, colY, colZ
FROM tblTableX
WHERE ID = @param
END

GO

Everything works very well in my asp page. But I've been reading about
COM and now I'd like to take it one step further and move the code
from my asp page into an active-x dll.

How do I run the stored procedure from the dll?

 

[Aaron [SQL Server MVP]]

Everything works very well in my asp page. But I've been reading about

COM and now I'd like to take it one step further and move the code
from my asp page into an active-x dll.

For what benefit?

How do I run the stored procedure from the dll?

Really not that much different, except you'll be using VB instead of
VBScript, I assume.
http://msdn.microsoft.com/library/en-us/dnvb600/html/404track.asp

 

[Alan Howard]

Porting any VBScript to a VB DLL is a straightforward process and has been
covered ad-nauseum in this and other newsgroups - a Google groups search
should help you out. What you're going to start asking though, are questions
about the architecture of the components that tend to grow out of this
work - business logic layer components, data access layer components, etc.
Look at a book called ASP.NET Website Programming - Problem, Design,
Solution, by Wrox. The authors build a website based on a tier and silo
architecture that I thought illustrates many useful concepts. The concepts
can be back-ported to VB/COM and this will give you some insight into one
way of designing and building these multi-tier architectures.

Alan

 

[Luis]

For what benefit?

The code contains some fancy calculations that are performed on the
data that is obtained from the database and I'l like to "protect"
those calculations.

Also, apparently "Compiled code is known to be more efficient than
interpreted code".

Really not that much different, except you'll be using VB instead of
VBScript, I assume.
http://msdn.microsoft.com/library/en-us/dnvb600/html/404track.asp

Thanks, that was a useful article!

 

[Aaron [SQL Server MVP]]

Also, apparently "Compiled code is known to be more efficient than

interpreted code".

Yes, that article was written back in 1999. Much more extensive tests has
been run since then, and I've tried to get the statement corrected.

A

 

[Luis]

Yes, that article was written back in 1999. Much more extensive tests has
been run since then, and I've tried to get the statement corrected.

Are you saying that the statement is incorrect - i.e. that compiled
code is NOT faster than interpreted code?

 

[Steven Burn]

If your wanting to protect the code, why not just store the file outside of
the webroot, and use the include in the page that uses it?

--

Regards

Steven Burn
Ur I.T. Mate Group
www.it-mate.co.uk

Keeping it FREE!

 

[Bob Barrows [MVP]]

Are you saying that the statement is incorrect - i.e. that compiled
code is NOT faster than interpreted code?

Without context, the statement is true: compiled code is faster than
interpreted code. However, this statement fails to consider other factors,
such as the time and resources to initialize the COM object, the time and
resources required to marshal data across processes, and the fact that code
execution speed is rarely the bottleneck during database access. Compiled
code waits just as long as interpreted code.

Bob Barrows