how to use precision

rajinikanth 2/2/2005 2:47:48 AM

This article is a blatant ripoff of the DBHelper class used in the FMStocks Microsoft application.

dave 4/11/2002 11:22:40 AM

Could you please supply the stored procedures needed in the samples?

Running the samples results in errors like this:
Fejltype:
Der opstod en Microsoft VBScript-kompileringsfejl (0x800A0401)
Slut på sætning var ventet
/pubs/ShowAuthors.asp, line 31, column 14
Begin Callout A
-------------^

The statement is not legal to IE. What is the problem ?

Best regards,
Bo Hansen

Bo Hansen 11/15/2001 6:33:01 AM

Great, but I'm looking for the "return value" (adParamReturnValue) as result of the execution of the SP...

Claudio Basso 8/28/2001 12:30:36 PM

This code is from the "Nile" example at MSDN, I'v been working with it for some time (it closely resembles the VB, COM+ Data Access Layer from the "Fitch & Mather 2000" example at MSDN too)

This code has a few issues:
1) The line
err.raise m_modName, "collectParams(...): incorrect # of parameters"
Is a leftover form the COM+ port and can't be run

2) In the method "RunSPReturnRS"
The line:
Set rs.ActiveConnection = Nothing
(sometimes ? allways?) gives an error that you can't modify a connection that belongs to a command object (I haven't found the cause of this yet)

3) The collectParams method does not support "Image" parameters (or "Memo" in access).

But it's good for building a standardised Data Access Layer and can easily be turned into a VB Com+ component (allthough you might want to get the already ported VB COM+ component from the "Fitch & Mather 2000" example at MSDN :-)

Kind Regards,
Allan Ebdrup, 10-4 ApS

Allan Ebdrup 8/6/2001 4:33:24 AM

This is a real time saver.....but what about sql-server generated errors?

alan scott 7/27/2001 10:41:03 AM

This is very helpful. However, there are two serious issues in this article: hard-coding SQL Server server name (this prevents portablility of code) and hard-coding the userid and password account (this is a security risk). To minimize this, consider using an ODBC source to mask the SQL Server server name and database name. Also consider using a resource file that has the userid and password separate from the code so that if there is a security breach, the userid and password can be changed with NO recoding. If possible, use NT Authentication (if so appropriate) that would eliminate the need for a specific userid and password.

Just suggestions from experience....
Thanks.

Eddy White 7/19/2001 12:07:44 PM

In the function
Begin Callout B
What is Callout? Is it a reserve word?

jd 7/11/2001 10:27:51 AM

Excellent article, but the "printer-friendly" option isn't. When used to print the right side of the document is chopped off. The only way I could print a copy that wasn't butchered was to copy into WORD.

Please let you web-master know he has some work to do.

alan spillert 7/3/2001 8:50:03 AM

This seems to work great for stored procs returning a single record set, but by utilizing the Server.CreateObject("adodb.Recordset") I get the following error when running stored procedures that return multiple record sets -- "ADODB.Recordset (0x800A0CB3)
Current provider does not support returning multiple recordsets from a single execution." Also, it gives me fits when I use the adParamReturnValue for the SQL Server RETURN value so I have gone back to the my previous way of calling stored procs using just the Command object until I find a way around all this. If anyone knows ways around these issues, please inform me.

Matt Stoddard 6/29/2001 11:07:52 AM