Thread: MaxLongVarChar and new lines in text
Hi,
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
insert a newline in the db like this: INSERT INTO test VALUES ('\n');
and then retrieve it from my odbc app and write the result to a file.
CommLogs and result files are attached.
When using a small MaxLongVarChar value the result is (in hex) 0a0d (new
line, carriage teturn). For large MaxLongVarChar its 000a (new line
only). Any Windows app requires both new line and carriage return to
display new line correct. Any reason why this should differ when using
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,
Åsmund Kveim Lie
Attachment
> 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
Åsmund Kveim Lie wrote:
> Hi,
>
> 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
> insert a newline in the db like this: INSERT INTO test VALUES ('\n');
> and then retrieve it from my odbc app and write the result to a file.
> CommLogs and result files are attached.
>
> When using a small MaxLongVarChar value the result is (in hex) 0a0d (new
> line, carriage teturn). For large MaxLongVarChar its 000a (new line
> only). Any Windows app requires both new line and carriage return to
> display new line correct. Any reason why this should differ when using
> 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
Hi,
No. In our registry settings we set MaxLongVarcharSize (and
TextAsLongVarchar = 1). We don’t even set MaxVarChar specifically, but
use default. I also noticed the difference in the log. I can send you
all of our settings if that gives you more information.
regards,
Åsmund K Lie
Hiroshi Inoue wrote:
> Åsmund Kveim Lie wrote:
>> Hi,
>>
>> 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
>> insert a newline in the db like this: INSERT INTO test VALUES ('\n');
>> and then retrieve it from my odbc app and write the result to a file.
>> CommLogs and result files are attached.
>>
>> When using a small MaxLongVarChar value the result is (in hex) 0a0d
>> (new line, carriage teturn). For large MaxLongVarChar its 000a (new
>> line only). Any Windows app requires both new line and carriage return
>> to display new line correct. Any reason why this should differ when
>> using 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
>
Åsmund Kveim Lie wrote: > Hi, > > No. In our registry settings we set MaxLongVarcharSize (and > TextAsLongVarchar = 1). We don’t even set MaxVarChar specifically, but > use default. Oh I see. It seems the driver's fault about debuggin output. Ok could you send me the Mylog output ? regards, Hiroshi Inoue
Hi Luf, The enhanced driver does not seem to work at all with MaxLongVarCharSize=-4 as the connect function returns false and the mylog ends with "[2112]DETACHING PROCESS". When using MaxLongVarCharSize=8190 I bump into another problem with my app when trying to fetch bytea: [Microsoft][ODBC Driver Manager] Invalid string or buffer length. It seems that this version of the driver is 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 considered stable for production use. regards, Åsmund Kveim Lie Ludek Finstrle wrote: >> 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 >
Åsmund Kveim Lie wrote: > Hi Luf, > > The enhanced driver does not seem to work at all with > MaxLongVarCharSize=-4 as the connect function returns false and the > mylog ends with "[2112]DETACHING PROCESS". Could you turn on the *Debug* option not only in the DataSource section but also in the Global section ? And Could you send me the mylog output ? > > When using MaxLongVarCharSize=8190 I bump into another problem with my > app when trying to fetch bytea: [Microsoft][ODBC Driver Manager] > Invalid string or buffer length. It seems that this version of the > driver is handling bytea's a little bit different and not quite ready > for my use. Could you send me the Mylog output ? regards, Hiroshi Inoue