How To Use GetChunk and AppendChunk Methods of RDO and ADO Object (153238)
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 for Windows 5.0
- Microsoft Visual Basic Enterprise Edition, 32-bit, for Windows 4.0
This article was previously published under Q153238 SUMMARY
This article describes how to use the GetChunk and AppendChunk methods of
an RDO and ADO column object. Included is the code for a working example of how to implement this behavior.
The GetChunk and AppendChunk methods work with the LongVarChar and
LongVarBinary column types, also known as TEXT and IMAGE columns, in
Microsoft SQL Server. To identify these column types in RDO, use the
<Column Object>.Type property that will return the constants rdLongVarChar
or rdLongVarBinary, or use the <Column object>.ChunkRequired property to
determine if you need to use the Get/AppendChunk methods to access the
column. Each of these column types is commonly referred to as Binary Large
Objects (BLOBs), so the term BLOB will be used for the remainder of this
article.
Following are some suggestions for using BLOBs with RDO:
- Using BLOB columns in a SQL table will cause performance degradation at
your server and add an extra layer of complexity in your application
code that you can avoid. If you are storing files such as Paintbrush
(.bmp), Microsoft Word (.doc), or just text (.txt) files, it is more
efficient to store these files in your file system than in your table.
You can do this by storing the UNC path for the file in a column of your
table, then letting your Visual Basic code read the path and handle the
file appropriately.
- When selecting a result set containing BLOB columns, you should place
the BLOB columns at the end of the select list. If you usually use the
"Select * from table" syntax, you should change this to "Select char1,
text1, image1 from table" to explicitly reference each column and place
the BLOB columns at the end.
- When editing a BLOB column using the AppendChunk method, you should
select at least one other editable non-BLOB column in your result set
and edit the non-BLOB column as well as the BLOB column. If you do not
edit the non-BLOB column, RDO will not raise an error but the data may
not be saved back to the base table.
- You cannot bind a BLOB value to a parameter marker because the
AppendChunk method is not available on the rdoParameter object. If you
want to pass a BLOB as an input parameter to a stored procedure, you
will have to utilize the ODBC handle from RDO to process this through
ODBC API calls. Fortunately, the ability to do this will be implemented
in all future versions of RDO following version 1.0x.
- If you are trying to display a bitmap image in a Picture control that
is stored in a LongVarBinary column, keep in mind that the Picture
control in Visual Basic does not have the capability of taking in a
stream of bits via Visual Basic Applications (VBA) code. The only way
to place a picture into the Picture control through code, or get the
bits back out of a Picture control through code, is to use a file on
the disk. You can also use the RDC and bind the Picture box to the BLOB
column. This works well for reads (displaying the Picture), but updates
are unstable in Visual Basic 4.0 due to problems in Visual Basic's
binding manager. To perform updates, you should use code, rather than
the RDC.
With the ODBC cursor library, it is not possible to use the GetChunk or
AppendChunk methods on a resultset returned from a stored procedure. This
is because the BLOB data does not come across the pipe with the rest of the
resultset. RDO has to go back and use the SQLGetData or SQLPutData ODBC AP
functions on the column when you request it with the RDO GetChunk or
AppendChunk methods. When a stored procedure creates a result set that is
returned to your application, RDO can use the data in the result set, but
it cannot go back to the base tables and columns and perform the
SQLGetData/SQLP tData because all it knows is that the SQL Statement was
something like "{call myproc(...)}", and there is no way for the cursor
library to know how to ask for the BLOB data because there is no base table
or column expressed there.
With server side cursors, it is possible to get at your BLOB data. The
server-side cursor knows the content of the stored procedure and can thus
get at the base table. A limitation of this is that you can't create a
server-side cursor based on a stored procedure that has anything besides
just one single select statement in it (a SQL Server restriction), so it is
pretty limiting and doubtful that you would be able to use this as your
primary technique.
The fact that users want to update their BLOB column demands that they
expose their base tables and create the cursor by using a standard select
statement from that base table. This would be true even if you were coding
directly to ODBC (not an RDO thing), as well as dbLibary (a proprietary SQL
Server API). If you use Jet, you can't update cursors based on stored
procedures at all because they always become read-only.
REFERENCES
Hitchhiker's Guide to Visual Basic and SQL Server, Microsoft Press.
ISBN: 1-55615-906-4.
For additional information, please see the following article in the
Microsoft Knowledge Base:
152715
: RDO 1.0b Release Now Available
Modification Type: | Minor | Last Reviewed: | 7/13/2004 |
---|
Keywords: | kbhowto KB153238 |
---|
|