MaxLongVarChar and new lines in text

This is a multi-part message in MIME format.
--------------060001090209070307080601
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

I'm having a problem with line breaks and the MaxLongVarChar setting.=20
I'm using Postgrsql 8.1.3 and ODBC version 08.01.0200(ansi). When I set
MaxLongVarChar <=3D 16383 it gives different results than using
MaxLongVarChar > 16383 or MaxLongVarChar =3D -4 (which is no limit). I
insert a newline in the db like this: INSERT INTO test VALUES ('\n');=20
and then retrieve it from my odbc app and write the result to a file.=20
CommLogs and result files are attached.

When using a small MaxLongVarChar value the result is (in hex) 0a0d (new=20
line, carriage teturn). For large MaxLongVarChar its 000a (new line=20
only). Any Windows app requires both new line and carriage return to=20
display new line correct. Any reason why this should differ when using=20
bigger values in MaxLongVarChar? We use the LF<->CR/LF conversion on.

I'm using 16383 in my app to day and it would be nice to increase this
without breaking my app.

Regards,

=C5smund Kveim Lie

--------------060001090209070307080601
Content-Type: application/octet-stream;
name="psqlodbc_5840.log"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="psqlodbc_5840.log"

Y29ubiA9IDcwOTkxMzA0LCBQR0FQSV9Db25uZWN0KERTTj0ncm9mdXMnLCBV
SUQ9J2hha29uaGMnLCBQV0Q9J3h4eHh4JykKR2xvYmFsIE9wdGlvbnM6IFZl
cnNpb249JzA4LjAxLjAyMDAnLCBmZXRjaD0xMDAsIHNvY2tldD0wLCB1bmtu
b3duX3NpemVzPTI1NCwgbWF4X3ZhcmNoYXJfc2l6ZT0tNCwgbWF4X2xvbmd2
YXJjaGFyX3NpemU9NzA5OTI3MTIKICAgICAgICAgICAgICAgIGRpc2FibGVf
b3B0aW1pemVyPTEsIGtzcW89MSwgdW5pcXVlX2luZGV4PTEsIHVzZV9kZWNs
YXJlZmV0Y2g9MAogICAgICAgICAgICAgICAgdGV4dF9hc19sb25ndmFyY2hh
cj0xLCB1bmtub3duc19hc19sb25ndmFyY2hhcj0wLCBib29sc19hc19jaGFy
PTEgTkFNRURBVEFMRU49NjQKICAgICAgICAgICAgICAgIGV4dHJhX3N5c3Rh
YmxlX3ByZWZpeGVzPSdkZF87JywgY29ubl9zZXR0aW5ncz0nJyBjb25uX2Vu
Y29kaW5nPSdPVEhFUicKY29ubj03MDk5MTMwNCwgcXVlcnk9J3NlbGVjdCB2
ZXJzaW9uKCknCiAgICBbIFBvc3RncmVTUUwgdmVyc2lvbiBzdHJpbmcgPSAn
UG9zdGdyZVNRTCA4LjEuMyBvbiBpNDg2LXBjLWxpbnV4LWdudSwgY29tcGls
ZWQgYnkgR0NDIGNjIChHQ0MpIDQuMC4zIDIwMDYwMjEyIChwcmVyZWxlYXNl
KSAoRGViaWFuIDQuMC4yLTkpJyBdCiAgICBbIFBvc3RncmVTUUwgdmVyc2lv
biBudW1iZXIgPSAnOC4xJyBdCmNvbm49NzA5OTEzMDQsIHF1ZXJ5PSdzZXQg
RGF0ZVN0eWxlIHRvICdJU08nJwpjb25uPTcwOTkxMzA0LCBxdWVyeT0nc2V0
IGdlcW8gdG8gJ09GRicnCmNvbm49NzA5OTEzMDQsIHF1ZXJ5PSdzZXQgZXh0
cmFfZmxvYXRfZGlnaXRzIHRvIDInCmNvbm49NzA5OTEzMDQsIHF1ZXJ5PSdz
ZWxlY3Qgb2lkIGZyb20gcGdfdHlwZSB3aGVyZSB0eXBuYW1lPSdsbycnCmNv
bm49NzA5OTEzMDQsIHF1ZXJ5PSdzZWxlY3QgcGdfY2xpZW50X2VuY29kaW5n
KCknCmNvbm49NzA5OTEzMDQsIHF1ZXJ5PSdzZXQgY2xpZW50X2VuY29kaW5n
IHRvICdsYXRpbjknJwpDT05OIEVSUk9SOiBmdW5jPVBHQVBJX1NldENvbm5l
Y3RPcHRpb24sIGRlc2M9J2ZPcHRpb249MTA0MSwgdlBhcmFtPTE2NjMyNDc2
JywgZXJybnVtPTIwNSwgc3Fsc3RhdGU9LCBlcnJtc2c9J1Vua25vd24gY29u
bmVjdCBvcHRpb24gKFNldCknCiAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQogICAgICAgICAgICBoZW52PTcwOTkxMjMyLCBjb25uPTcwOTkxMzA0LCBz
dGF0dXM9MSwgbnVtX3N0bXRzPTE2CkNPTk4gRVJST1I6IGZ1bmM9UEdBUElf
U2V0Q29ubmVjdE9wdGlvbiwgZGVzYz0nZk9wdGlvbj0xMDQyLCB2UGFyYW09
MTY2MzI0NzYnLCBlcnJudW09MjA1LCBzcWxzdGF0ZT0sIGVycm1zZz0nVW5r
bm93biBjb25uZWN0IG9wdGlvbiAoU2V0KScKICAgICAgICAgICAgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tCiAgICAgICAgICAgIGhlbnY9NzA5OTEyMzIsIGNvbm49NzA5
OTEzMDQsIHN0YXR1cz0xLCBudW1fc3RtdHM9MTYKY29ubj03MDk5MTMwNCwg
cXVlcnk9J1NFTEVDVCB2ZXJzaW9uKCknCmNvbm49NzA5OTEzMDQsIHF1ZXJ5
PSdTRUxFQ1QgKiBGUk9NIHRlc3QnCmNvbm49NzA5OTEzMDQsIFBHQVBJX0Rp
c2Nvbm5lY3QK

--------------060001090209070307080601
Content-Type: application/octet-stream;
name="psqlodbc_5600.log"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="psqlodbc_5600.log"

Y29ubiA9IDcwOTkxMzA0LCBQR0FQSV9Db25uZWN0KERTTj0ncm9mdXMnLCBV
SUQ9J2hha29uaGMnLCBQV0Q9J3h4eHh4JykKR2xvYmFsIE9wdGlvbnM6IFZl
cnNpb249JzA4LjAxLjAyMDAnLCBmZXRjaD0xMDAsIHNvY2tldD0wLCB1bmtu
b3duX3NpemVzPTI1NCwgbWF4X3ZhcmNoYXJfc2l6ZT0xNjM4MywgbWF4X2xv
bmd2YXJjaGFyX3NpemU9NzA5OTI3MTIKICAgICAgICAgICAgICAgIGRpc2Fi
bGVfb3B0aW1pemVyPTEsIGtzcW89MSwgdW5pcXVlX2luZGV4PTEsIHVzZV9k
ZWNsYXJlZmV0Y2g9MAogICAgICAgICAgICAgICAgdGV4dF9hc19sb25ndmFy
Y2hhcj0xLCB1bmtub3duc19hc19sb25ndmFyY2hhcj0wLCBib29sc19hc19j
aGFyPTEgTkFNRURBVEFMRU49NjQKICAgICAgICAgICAgICAgIGV4dHJhX3N5
c3RhYmxlX3ByZWZpeGVzPSdkZF87JywgY29ubl9zZXR0aW5ncz0nJyBjb25u
X2VuY29kaW5nPSdPVEhFUicKY29ubj03MDk5MTMwNCwgcXVlcnk9J3NlbGVj
dCB2ZXJzaW9uKCknCiAgICBbIFBvc3RncmVTUUwgdmVyc2lvbiBzdHJpbmcg
PSAnUG9zdGdyZVNRTCA4LjEuMyBvbiBpNDg2LXBjLWxpbnV4LWdudSwgY29t
cGlsZWQgYnkgR0NDIGNjIChHQ0MpIDQuMC4zIDIwMDYwMjEyIChwcmVyZWxl
YXNlKSAoRGViaWFuIDQuMC4yLTkpJyBdCiAgICBbIFBvc3RncmVTUUwgdmVy
c2lvbiBudW1iZXIgPSAnOC4xJyBdCmNvbm49NzA5OTEzMDQsIHF1ZXJ5PSdz
ZXQgRGF0ZVN0eWxlIHRvICdJU08nJwpjb25uPTcwOTkxMzA0LCBxdWVyeT0n
c2V0IGdlcW8gdG8gJ09GRicnCmNvbm49NzA5OTEzMDQsIHF1ZXJ5PSdzZXQg
ZXh0cmFfZmxvYXRfZGlnaXRzIHRvIDInCmNvbm49NzA5OTEzMDQsIHF1ZXJ5
PSdzZWxlY3Qgb2lkIGZyb20gcGdfdHlwZSB3aGVyZSB0eXBuYW1lPSdsbycn
CmNvbm49NzA5OTEzMDQsIHF1ZXJ5PSdzZWxlY3QgcGdfY2xpZW50X2VuY29k
aW5nKCknCmNvbm49NzA5OTEzMDQsIHF1ZXJ5PSdzZXQgY2xpZW50X2VuY29k
aW5nIHRvICdsYXRpbjknJwpDT05OIEVSUk9SOiBmdW5jPVBHQVBJX1NldENv
bm5lY3RPcHRpb24sIGRlc2M9J2ZPcHRpb249MTA0MSwgdlBhcmFtPTE2NjMy
NDc2JywgZXJybnVtPTIwNSwgc3Fsc3RhdGU9LCBlcnJtc2c9J1Vua25vd24g
Y29ubmVjdCBvcHRpb24gKFNldCknCiAgICAgICAgICAgIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQogICAgICAgICAgICBoZW52PTcwOTkxMjMyLCBjb25uPTcwOTkxMzA0
LCBzdGF0dXM9MSwgbnVtX3N0bXRzPTE2CkNPTk4gRVJST1I6IGZ1bmM9UEdB
UElfU2V0Q29ubmVjdE9wdGlvbiwgZGVzYz0nZk9wdGlvbj0xMDQyLCB2UGFy
YW09MTY2MzI0NzYnLCBlcnJudW09MjA1LCBzcWxzdGF0ZT0sIGVycm1zZz0n
VW5rbm93biBjb25uZWN0IG9wdGlvbiAoU2V0KScKICAgICAgICAgICAgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCiAgICAgICAgICAgIGhlbnY9NzA5OTEyMzIsIGNvbm49
NzA5OTEzMDQsIHN0YXR1cz0xLCBudW1fc3RtdHM9MTYKY29ubj03MDk5MTMw
NCwgcXVlcnk9J1NFTEVDVCB2ZXJzaW9uKCknCmNvbm49NzA5OTEzMDQsIHF1
ZXJ5PSdTRUxFQ1QgKiBGUk9NIHRlc3QnCmNvbm49NzA5OTEzMDQsIFBHQVBJ
X0Rpc2Nvbm5lY3QK

--------------060001090209070307080601
Content-Type: application/octet-stream;
name="8.1-16383"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="8.1-16383"

DQo=

--------------060001090209070307080601
Content-Type: application/octet-stream;
name="8.1-4"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="8.1-4"

Cg==

--------------060001090209070307080601
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--------------060001090209070307080601--

Re: MaxLongVarChar and new lines in text

> I'm having a problem with line breaks and the MaxLongVarChar setting.
> I'm using Postgrsql 8.1.3 and ODBC version 08.01.0200(ansi). When I set
> MaxLongVarChar <= 16383 it gives different results than using
> MaxLongVarChar > 16383 or MaxLongVarChar = -4 (which is no limit). I

Hello,

could you try new 7.3.260 (enhanced branch) version? It's downloadable
from www.pgfoundry.org.

Hiroshi doesn't become the time for releasing 7.3.261? Or at least could
you put patched 7.3.260 on pgfoundry? I know you put it somewhere on the
net but I didn't remember the URL.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: MaxLongVarChar and new lines in text

=C5smund Kveim Lie wrote:
> Hi,
>=20
> I'm having a problem with line breaks and the MaxLongVarChar setting.=20
> I'm using Postgrsql 8.1.3 and ODBC version 08.01.0200(ansi). When I set
> MaxLongVarChar <=3D 16383 it gives different results than using
> MaxLongVarChar > 16383 or MaxLongVarChar =3D -4 (which is no limit). I
> insert a newline in the db like this: INSERT INTO test VALUES ('\n');=20
> and then retrieve it from my odbc app and write the result to a file.=20
> CommLogs and result files are attached.
>=20
> When using a small MaxLongVarChar value the result is (in hex) 0a0d (ne=
w=20
> line, carriage teturn). For large MaxLongVarChar its 000a (new line=20
> only). Any Windows app requires both new line and carriage return to=20
> display new line correct. Any reason why this should differ when using=20
> bigger values in MaxLongVarChar? We use the LF<->CR/LF conversion on.

Just a confirmation.
Aren't you setting MaxVarChar not MaxLongVarChar ?

regards,
Hiroshi Inoue

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: MaxLongVarChar and new lines in text

Hi,

No. In our registry settings we set MaxLongVarcharSize (and=20
TextAsLongVarchar =3D 1). We don=92t even set MaxVarChar specifically, bu=
t=20
use default. I also noticed the difference in the log. I can send you=20
all of our settings if that gives you more information.

regards,

=C5smund K Lie

Hiroshi Inoue wrote:
> =C5smund Kveim Lie wrote:
>> Hi,
>>
>> I'm having a problem with line breaks and the MaxLongVarChar setting.=20
>> I'm using Postgrsql 8.1.3 and ODBC version 08.01.0200(ansi). When I se=
t
>> MaxLongVarChar <=3D 16383 it gives different results than using
>> MaxLongVarChar > 16383 or MaxLongVarChar =3D -4 (which is no limit). I
>> insert a newline in the db like this: INSERT INTO test VALUES ('\n');=20
>> and then retrieve it from my odbc app and write the result to a file.=20
>> CommLogs and result files are attached.
>>
>> When using a small MaxLongVarChar value the result is (in hex) 0a0d=20
>> (new line, carriage teturn). For large MaxLongVarChar its 000a (new=20
>> line only). Any Windows app requires both new line and carriage return=
=20
>> to display new line correct. Any reason why this should differ when=20
>> using bigger values in MaxLongVarChar? We use the LF<->CR/LF=20
>> conversion on.
>=20
> Just a confirmation.
> Aren't you setting MaxVarChar not MaxLongVarChar ?
>=20
> regards,
> Hiroshi Inoue
>=20
> ---------------------------(end of broadcast)--------------------------=
-
> TIP 6: explain analyze is your friend
>=20



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: MaxLongVarChar and new lines in text

=C5smund Kveim Lie wrote:
> Hi,
>=20
> No. In our registry settings we set MaxLongVarcharSize (and=20
> TextAsLongVarchar =3D 1). We don=92t even set MaxVarChar specifically, =
but=20
> use default.=20

Oh I see. It seems the driver's fault about debuggin output.
Ok could you send me the Mylog output ?

regards,
Hiroshi Inoue

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

Re: MaxLongVarChar and new lines in text

Hi Luf,

The enhanced driver does not seem to work at all with=20
MaxLongVarCharSize=3D-4 as the connect function returns false and the=20
mylog ends with "[2112]DETACHING PROCESS".

When using MaxLongVarCharSize=3D8190 I bump into another problem with my=20
app when trying to fetch bytea: [Microsoft][ODBC Driver Manager] Invalid=20
string or buffer length. It seems that this version of the driver is=20
handling bytea's a little bit different and not quite ready for my use.

I would prefer to use the 08.01.200 driver until the enhanced branch is=20
considered stable for production use.

regards,

=C5smund Kveim Lie

Ludek Finstrle wrote:
>> I'm having a problem with line breaks and the MaxLongVarChar setting.=20
>> I'm using Postgrsql 8.1.3 and ODBC version 08.01.0200(ansi). When I se=
t
>> MaxLongVarChar <=3D 16383 it gives different results than using
>> MaxLongVarChar > 16383 or MaxLongVarChar =3D -4 (which is no limit). I
>=20
> Hello,
>=20
> could you try new 7.3.260 (enhanced branch) version? It's downloadabl=
e
> from www.pgfoundry.org.
>=20
> Hiroshi doesn't become the time for releasing 7.3.261? Or at least coul=
d
> you put patched 7.3.260 on pgfoundry? I know you put it somewhere on th=
e
> net but I didn't remember the URL.
>=20
> Regards,
>=20
> Luf
>=20
> ---------------------------(end of broadcast)--------------------------=
-
> TIP 4: Have you searched our list archives?
>=20
> http://archives.postgresql.org
>=20



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: MaxLongVarChar and new lines in text

=C5smund Kveim Lie wrote:

> Hi Luf,
>
> The enhanced driver does not seem to work at all with=20
> MaxLongVarCharSize=3D-4 as the connect function returns false and the=20
> mylog ends with "[2112]DETACHING PROCESS".


Could you turn on the *Debug* option not only in the DataSource section=20
but also in the Global section ?
And Could you send me the mylog output ?

>
> When using MaxLongVarCharSize=3D8190 I bump into another problem with m=
y=20
> app when trying to fetch bytea: [Microsoft][ODBC Driver Manager]=20
> Invalid string or buffer length. It seems that this version of the=20
> driver is handling bytea's a little bit different and not quite ready=20
> for my use.


Could you send me the Mylog output ?

regards,
Hiroshi Inoue

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org