Thread: Large objects truncated when retrieved

Large objects truncated when retrieved

From
Xavier Le Vourch
Date:
I'm storing pictures in a table using the lo type definition from the
FAQ. The server version is 7.2.3 and the odbc driver is 7.3.100.

The images are stored correctly and can be retrieved on the server fine
using psql but the odbc driver truncates the objects at 32k+1 on the
retrieve (they were stored correctly though).

I've tried to increase the MaxLongVarChar setting in the datasource
definition or even set it to -4, according to the HOWTO describing the
configuration options but nothing works.

What is the correct way to increase the limit on large objects in the
odbc driver?

Thanks,
Xavier

--
Xavier Le Vourch
Brittany Software, Inc.
<xavier@brittanysoftware.com>

PGP Key: http://brittanysoftware.com/gpg_key.asc






Re: Large objects truncated when retrieved

From
"Hiroshi Inoue"
Date:
> -----Original Message-----
> From: Xavier Le Vourch
> Sent: Saturday, October 04, 2003 3:48 AM
>
> I'm storing pictures in a table using the lo type definition from the
> FAQ. The server version is 7.2.3 and the odbc driver is 7.3.100.
>
> The images are stored correctly and can be retrieved on the
> server fine
> using psql but the odbc driver truncates the objects at 32k+1 on the
> retrieve (they were stored correctly though).

Which data type are you using to store the images ?
And what kind of tools are you using ?
In most cases tools have their own limitations.

regards,
Hiroshi Inoue


Re: Large objects truncated when retrieved

From
Xavier Le Vourch
Date:
Hiroshi Inoue wrote:

>>-----Original Message-----
>>From: Xavier Le Vourch
>>Sent: Saturday, October 04, 2003 3:48 AM
>>
>>I'm storing pictures in a table using the lo type definition from the
>>FAQ. The server version is 7.2.3 and the odbc driver is 7.3.100.
>>
>>The images are stored correctly and can be retrieved on the
>>server fine
>>using psql but the odbc driver truncates the objects at 32k+1 on the
>>retrieve (they were stored correctly though).
>
>
> Which data type are you using to store the images ?

I'm using the lo type defined in the FAQ at:

http://gborg.postgresql.org/project/psqlodbc/faq/faq.php?faq_id=52


> And what kind of tools are you using ?
> In most cases tools have their own limitations.
>

I'm using Borland C++ 6 but the problem seems to be coming from the
driver as when I enabled logging, I get messages like:

conn=67191248, query='COMMIT'
The 2th item was truncated
The buffer size = 32769 and the value is '1040924'

even when I modified Max LongVarChar in the data source.

If the image size is less than 32769, it works but anything larger than
that will be truncated on the retrieval only.


Best regards,
Xavier

--
Xavier Le Vourch
Brittany Software, Inc.
<xavier@brittanysoftware.com>

PGP Key: http://brittanysoftware.com/gpg_key.asc





Re: Large objects truncated when retrieved

From
"Hiroshi Inoue"
Date:
> -----Original Message-----
> From: Xavier Le Vourch
>
> Hiroshi Inoue wrote:
>
> >>-----Original Message-----
> >>From: Xavier Le Vourch
> >>Sent: Saturday, October 04, 2003 3:48 AM
> >>
> >>I'm storing pictures in a table using the lo type
> definition from the
> >>FAQ. The server version is 7.2.3 and the odbc driver is 7.3.100.
> >>
> >>The images are stored correctly and can be retrieved on the
> >>server fine
> >>using psql but the odbc driver truncates the objects at
> 32k+1 on the
> >>retrieve (they were stored correctly though).
> >
> >
> > Which data type are you using to store the images ?
>
> I'm using the lo type defined in the FAQ at:
>
> > And what kind of tools are you using ?
> > In most cases tools have their own limitations.

> I'm using Borland C++ 6 but the problem seems to be coming from the
> driver as when I enabled logging, I get messages like:

> conn=67191248, query='COMMIT'
> The 2th item was truncated
> The buffer size = 32769 and the value is '1040924'

Could you send me the Mylog debug output ?

regards,
Hiroshi Inoue





---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster