Thread: problem with 09.0.0200

Hi,
I just upgraded some LAN PCs from the last 0.8.04 to 09.0.0200 after a
longer testing period on my own box.
Now a user complaines that he couldn't login anymore with MS-Access.
Dropping back to the last 08-driver cleared the issue.

The problem is a "%" character within the password.
Passwords without % do work OK. There might be other signes hat won't
work though.

Is this an error in my connection string or should it rather be minded
somewhere in the driver?

Generally I'm freightend that there is a deeper problem that just shows
here for now and hides elsewhere to kick me later so I went back to
0.8... for the time beeing.

Is there someone that could shed some light on this?

Hi Andreas,

(2011/04/13 12:02), Andreas wrote:
> Hi,
> I just upgraded some LAN PCs from the last 0.8.04 to 09.0.0200 after a
> longer testing period on my own box.
> Now a user complaines that he couldn't login anymore with MS-Access.
> Dropping back to the last 08-driver cleared the issue.
>
> The problem is a "%" character within the password.
> Passwords without % do work OK. There might be other signes hat won't
> work though.

Maybe % is treated as an escape character.
Could you please try %% instead of %?

regards,
Hiroshi Inoue

> Is this an error in my connection string or should it rather be minded
> somewhere in the driver?
>
> Generally I'm freightend that there is a deeper problem that just shows
> here for now and hides elsewhere to kick me later so I went back to
> 0.8... for the time beeing.
>
> Is there someone that could shed some light on this?

Hi,

(2011/04/13 21:09), Raiford@labware.com wrote:
> I have an issue where even though I break a large BYTEA object up into
> multiple pieces, the ODBC driver just rejoins the pieces in memory and
> tries to send it all out at once. I took a look at the code and sure
> enough the driver just keeps reallocating memory for each chunk of data
> that I add.

Yes you are right.

 > Can I assume Postgres has no mechanism to send this data
> across the wire in pieces? Are there any common practices for dealing
> with this?

Please try lo type instead of bytea type.

regards,
Hiroshi Inoue

 > As it is, in one environment I can only transfer files around
> 50MB before I start receiving out of memory errors. The same program
> running against Oracle and SQL Server works great.
>
> Jon

(2011/04/14 21:17), Raiford@labware.com wrote:
> Hi Hiroshi-san,
>
> Thank you for your response. Could you clarify one thing for me? Are you
> suggesting that when using an lo datatype with the lo module installed,

You don't have to install the lo module. Please type

    create domain lo as oid;

and use the lo type.

> the ODBC driver automatically sends the data in pieces?

Yes.

regards,
Hiroshi Inoue

 > Or does it only
> open the possibility for me to use the lo_import() function? If
> everything is handled internally in the ODBC driver, it would certainly
> help a lot :)
>
> Jon
>
> From: Hiroshi Inoue <inoue@tpf.co.jp>
> To: Raiford@labware.com
> Cc: pgsql-odbc@postgresql.org
> Date: 04/13/2011 11:42 PM
> Subject: Re: [ODBC] BYTEA Fields and Memory Consumption
> Sent by: pgsql-odbc-owner@postgresql.org
> ------------------------------------------------------------------------
>
> Hi,
>
> (2011/04/13 21:09), Raiford@labware.com wrote:
>  > I have an issue where even though I break a large BYTEA object up into
>  > multiple pieces, the ODBC driver just rejoins the pieces in memory and
>  > tries to send it all out at once. I took a look at the code and sure
>  > enough the driver just keeps reallocating memory for each chunk of data
>  > that I add.
>
> Yes you are right.
>
>  > Can I assume Postgres has no mechanism to send this data
>  > across the wire in pieces? Are there any common practices for dealing
>  > with this?
>
> Please try lo type instead of bytea type.
>
> regards,
> Hiroshi Inoue

In my experience even when using 'lo' the driver only got the first
chunk of data which is equal to the length of the buffer that client
provided and never went back to ask for next chunk.

Also, I am not sure how one can read multiple blocks from client code?

Ramesh..

On Fri, 2011-04-15 at 08:42 +0900, Hiroshi Inoue wrote:
> (2011/04/14 21:17), Raiford@labware.com wrote:
> > Hi Hiroshi-san,
> >
> > Thank you for your response. Could you clarify one thing for me? Are you
> > suggesting that when using an lo datatype with the lo module installed,
>
> You don't have to install the lo module. Please type
>
>     create domain lo as oid;
>
> and use the lo type.
>
> > the ODBC driver automatically sends the data in pieces?
>
> Yes.
>
> regards,
> Hiroshi Inoue
>
>  > Or does it only
> > open the possibility for me to use the lo_import() function? If
> > everything is handled internally in the ODBC driver, it would certainly
> > help a lot :)
> >
> > Jon
> >
> > From: Hiroshi Inoue <inoue@tpf.co.jp>
> > To: Raiford@labware.com
> > Cc: pgsql-odbc@postgresql.org
> > Date: 04/13/2011 11:42 PM
> > Subject: Re: [ODBC] BYTEA Fields and Memory Consumption
> > Sent by: pgsql-odbc-owner@postgresql.org
> > ------------------------------------------------------------------------
> >
> > Hi,
> >
> > (2011/04/13 21:09), Raiford@labware.com wrote:
> >  > I have an issue where even though I break a large BYTEA object up into
> >  > multiple pieces, the ODBC driver just rejoins the pieces in memory and
> >  > tries to send it all out at once. I took a look at the code and sure
> >  > enough the driver just keeps reallocating memory for each chunk of data
> >  > that I add.
> >
> > Yes you are right.
> >
> >  > Can I assume Postgres has no mechanism to send this data
> >  > across the wire in pieces? Are there any common practices for dealing
> >  > with this?
> >
> > Please try lo type instead of bytea type.
> >
> > regards,
> > Hiroshi Inoue
>

Hi Ramesh,

(2011/04/15 8:48), Ramesh Reddy wrote:
> In my experience even when using 'lo' the driver only got the first
> chunk of data which is equal to the length of the buffer that client
> provided and never went back to ask for next chunk.

Clients have to call some special API/methods provided by the
interface they are using, e.g. ODBC native apps calls SQLPutData(),
  ADO apps calls AppendChunk().

regards,
Hiroshi Inoue

> Also, I am not sure how one can read multiple blocks from client code?
>
> Ramesh..
>
> On Fri, 2011-04-15 at 08:42 +0900, Hiroshi Inoue wrote:
>> (2011/04/14 21:17), Raiford@labware.com wrote:
>>> Hi Hiroshi-san,
>>>
>>> Thank you for your response. Could you clarify one thing for me? Are you
>>> suggesting that when using an lo datatype with the lo module installed,
>>
>> You don't have to install the lo module. Please type
>>
>>     create domain lo as oid;
>>
>> and use the lo type.
>>
>>> the ODBC driver automatically sends the data in pieces?
>>
>> Yes.
>>
>> regards,
>> Hiroshi Inoue
>>
>>   >  Or does it only
>>> open the possibility for me to use the lo_import() function? If
>>> everything is handled internally in the ODBC driver, it would certainly
>>> help a lot :)
>>>
>>> Jon
>>>
>>> From: Hiroshi Inoue<inoue@tpf.co.jp>
>>> To: Raiford@labware.com
>>> Cc: pgsql-odbc@postgresql.org
>>> Date: 04/13/2011 11:42 PM
>>> Subject: Re: [ODBC] BYTEA Fields and Memory Consumption
>>> Sent by: pgsql-odbc-owner@postgresql.org
>>> ------------------------------------------------------------------------
>>>
>>> Hi,
>>>
>>> (2011/04/13 21:09), Raiford@labware.com wrote:
>>>   >  I have an issue where even though I break a large BYTEA object up into
>>>   >  multiple pieces, the ODBC driver just rejoins the pieces in memory and
>>>   >  tries to send it all out at once. I took a look at the code and sure
>>>   >  enough the driver just keeps reallocating memory for each chunk of data
>>>   >  that I add.
>>>
>>> Yes you are right.
>>>
>>>   >  Can I assume Postgres has no mechanism to send this data
>>>   >  across the wire in pieces? Are there any common practices for dealing
>>>   >  with this?
>>>
>>> Please try lo type instead of bytea type.
>>>
>>> regards,
>>> Hiroshi Inoue