problem with 09.0.0200

problem with 09.0.0200

am 13.04.2011 05:02:07 von Andreas

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?

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: problem with 09.0.0200

am 13.04.2011 05:24:42 von Hiroshi Inoue

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?


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

BYTEA Fields and Memory Consumption

am 13.04.2011 14:09:25 von Raiford

This is a multipart message in MIME format.
--=_alternative 0042C71685257871_=
Content-Type: text/plain; charset="US-ASCII"

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. 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? 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
--=_alternative 0042C71685257871_=
Content-Type: text/html; charset="US-ASCII"

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.  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?  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
--=_alternative 0042C71685257871_=--

Re: BYTEA Fields and Memory Consumption

am 14.04.2011 05:41:45 von Hiroshi Inoue

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


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: BYTEA Fields and Memory Consumption

am 14.04.2011 14:17:38 von Raiford

This is a multipart message in MIME format.
--=_alternative 004387CD85257872_=
Content-Type: text/plain; charset="US-ASCII"

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,
the ODBC driver automatically sends the data in pieces? 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
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

> 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


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc


--=_alternative 004387CD85257872_=
Content-Type: text/html; charset="US-ASCII"

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, the ODBC driver automatically
sends the data in pieces?  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



> 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





--

Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)

To make changes to your subscription:






--=_alternative 004387CD85257872_=--

Re: BYTEA Fields and Memory Consumption

am 15.04.2011 01:42:05 von Hiroshi Inoue

(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
> 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

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: BYTEA Fields and Memory Consumption

am 15.04.2011 01:48:21 von Ramesh Reddy

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
> > 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
>



--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: BYTEA Fields and Memory Consumption

am 15.04.2011 05:34:51 von 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
>>> 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

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc