Skip to Content.
Sympa Menu

freetds - RE: [freetds] Problem with dbrpcparam

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Problem with dbrpcparam
  • Date: Thu, 21 Apr 2005 12:09:22 -0400

> From: Michael Peppler
> Sent: Thursday, April 21, 2005 11:53 AM
>
> On Thu, 2005-04-21 at 15:54, martin martin wrote:
> > Hello, I have some problems passing binary data to stored procedures
using
> > db-lib. The parameter is a SYBIMAGE(IMAGE TYPE IN SQLSERVER)
>
> I don't know about MS-SQL, but for Sybase you can't pass IMAGE types
as
> parameters to a stored proc, and this may be reflected in the
DB-Library
> API.

That was my initial reaction, and I probably relied on the Sybase docs.
At some point along the way, though Microsoft lifted that restriction.
On our 2000 server, I wrote a procedure that accepts a TEXT parameter.
And the dbrpcparam Books Online entry includes this:

===
maxlen

For variable-length return parameters (when type is SQLCHAR, SQLBINARY,
SQLTEXT, or SQLIMAGE), maxlen is the maximum desired byte length for the
value parameter returned from a stored procedure.
===

It's a little hard to imagine managing image data as a parameter in the
general case. Parameters (as we implement them) reside in virtual
memory, which a single TEXT parameter could potentially exhaust on a
32-bit machine. But I can see how in the non-general case it would be
convenient. A varchar can be 8000 bytes; if your document is 15,000
bytes, it would be nice to be able to treat as a "supervarchar".

--jkl


-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named
above. If you are not the intended recipient, or an employee or agent
responsible
for delivering this message to the intended recipient, any review,
dissemination,
distribution or duplication of this communication is strictly prohibited. If
you are
not the intended recipient, please contact the sender immediately by reply
e-mail
and destroy all copies of the original message. Please note that we do not
accept
account orders and/or instructions by e-mail, and therefore will not be
responsible
for carrying out such orders and/or instructions. If you, as the intended
recipient
of this message, the purpose of which is to inform and update our clients,
prospects
and consultants of developments relating to our services and products, would
not
like to receive further e-mail correspondence from the sender, please "reply"
to the
sender indicating your wishes. In the U.S.: 1345 Avenue of the Americas, New
York,
NY 10105.




Archive powered by MHonArc 2.6.24.

Top of Page