RDO: Getting Data from Temp Tables Created by Stored Procedure (147938)
The information in this article applies to:
- Microsoft Visual Basic Learning Edition for Windows 6.0
- Microsoft Visual Basic Professional Edition for Windows 6.0
- Microsoft Visual Basic Enterprise Edition for Windows 6.0
- Microsoft Visual Basic Enterprise Edition, 32-bit, for Windows 4.0
This article was previously published under Q147938 SUMMARY It is common to have stored procedures use temporary tables
to build a result set. When using RDO (Remote Data Object) to call this type of
stored procedure it appears as though RDO does not return any results, only an
empty result set and no errors.
Testing this same query with the
Microsoft SQL Server version 6.0 ISQL utility produces the expected results,
which leads you to believe RDO is restricted from reading these temporary
tables.
This is not an RDO restriction and RDO CAN retrieve data
from a temporary table created in a stored procedure. However, no data access
library can create a SCROLLABLE CURSOR on a temporary table created within a
stored procedure. Temporary tables that are created within a stored procedure
are DESTROYED when that stored procedure ends. If the table is not there, no
data access library can possibly open a scrollable cursor on it, and go back to
it when the next rowset is needed or when the user tries to update, insert or
delete it.
ISQL does not open a cursor, nor use a cursor library, so
it just reads data off the pipe, one row at a time, read-only, forward-only
(this is also the default mode of dblib so many people are used to working this
way). The good news is that RDO can do this as well. You just need to tell SQL
Server not to open a server-side cursor on the temporary table. This is done by
setting the RowsetSize property to 1 and opening the result set as forward-only
and read-only (just like ISQL does). RDO uses 100 as the default for
RowsetSize, since this is the optimal setting for most cursor operations and
when it is set to anything greater than 1, SQL Server' ODBC driver MUST attempt
to create a server-side cursor, since fat rowsets require the ability to scroll
and possibly update.
Remember that using cursors is much different
than the read-only, forward-only, rowset size of 1, approach to getting data
back to the client. To support the operations that cursors do (like scrolling
backwards, doing positioned updates, etc.), the source of the data has to live
for the entire time the cursor is open. RDO can operate in a cursor mode, or a
"fire hose" mode, which allows you to perform whatever functionality you want.
REFERENCES For complete documentation, refer to the "Microsoft ODBC
2.0
Programmer's Reference and SDK Guide."
Hitchhiker's Guide to Visual Basic and SQL Server, Microsoft Press.
ISBN: 1-55615-906-4.).
Modification Type: | Major | Last Reviewed: | 11/3/2003 |
---|
Keywords: | KB147938 |
---|
|