Message-ID: <36930F2C.9746725C@perio.unlp.edu.ar>
Date: Wed, 06 Jan 1999 04:22:20 -0300
From: Sergio Kessler <ser@perio.unlp.edu.ar>
MIME-Version: 1.0
To: Byron Nikolaidis <byronn@insightdist.com>, pgsql-interfaces@postgreSQL.org
Subject: Re: Multiple SQLGetData?
References: <36922807.8EA62906@insightdist.com>
	<3691D7CC.648ADF2C@perio.unlp.edu.ar>
	<369462F8.B43F60D3@insightdist.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Byron Nikolaidis wrote:
> 
> Sergio Kessler wrote:
> 
> > well, is a little funny because it seems that a change in the driver
> > has changed the type of text fields to non binary, in my code I do
> > something like:
> >
> >        if SQLDataType=SQL_BINARY then
> >        begin
> >           // load blob fields
> >           c:='';
> >           sqlres:=SQLGetData(hstmt, FieldNo, SQL_BINARY, SQLPOINTER(
> > @i),
> >                              0, @iv);
> >
> >
> > but now, with the new driver the flow of the program no longer
> > run this code, text fields are managed by the code that deal
> > with normal fields :o
> > And all seems running smoothly ...
> >
> > I will try to make new tables that contain real binary fields
> > and let you know if it worked or not, just give me a few days.
> >
> 
> There is a small problem with the way BINARY and VARBINARY are mapped in the
> driver since we do not have very good binary data types in Postgres.  Try
> changing the test condition to check for SQL_VARBINARY instead.   Can you
> tell me where your variable "SQLDataType" comes from?

Very good question ;)

SQLDataType comes from a call to SQLDescribeCol and if the result of
this function (the sixth parameter) is SQL_BINARY or SQL_VARBINARY 
or SQL_LONGVARBINARY or SQL_LONGVARCHAR i'm setting it to  
SQLDataType := SQL_BINARY
so a change to the above code is useless, in reality I'm using it
in the way of: 'hey, this field is variable length and first I must
know the size, then retrieve it'

then I decided to debug the part of SQLDescribeCol, and I see
that the text field return like a SQL_VARCHAR, I was expecting a 
SQL_LONGVARCHAR...

and here the better of the show :) 
SQLDescribeCol return 254 like ColumnSize (seventh parameter), so
I tried to put a text larger than 254 chars, and according with
what I was expecting the text was truncated at 254 chars.

> I don't know what source code you are looking at, but the latest code for
> SQLGetData does indeed return SQL_SUCCESS_WITH_INFO when there will be a
> truncation.  Make sure you are looking at the right version, either from our
> web site (postsrc.zip) or some other correct place.

yap, I download it again and I see it now ...

-- 
Who is the General Failure and what f* do reading my disk !?
--
Sergio Kessler

pd: I'm sending this also to the list for security, yesterday
I receive a bounced email, and I will not be online for the rest
of the day.