C-style new line characters

v10.01
I updated a table in ISQL and in my app along the lines of
UPDATE "people" SET "col"='abc\nmo' etc
then "select cast(col as binary) etc" gives
[97, 98, 99, 10, 109, 111] - i.e. the \n was changed to new line character
While
UPDATE "people" SET "col"='abc\nmo\t12\r34' ...;
gives
abc
mo\t12\r34
The tab and carriage return are not interprted C-style; just the \n. So why 
is the \n? When did this happen? Why does this happen? Can I turn this 
behaviour off ? Yes I can escape it with another \ but that doesn't really 
help at this stage. When did the DB start talking C?
Thanks
Clive 

0
Clive
4/29/2008 8:17:41 AM
📁 sybase.sqlanywhere.general
📃 32637 articles.
⭐ 22 followers.

💬 6 Replies
👁️‍🗨️ 897 Views


Clive,
The \n being a newline in char literals is the behavior of SQL Anywhere =
at  =
least since version 5. I am not aware of an option or something like thi=
s  =
to switch this behavior off.
Maybe it would be worth to ask for a connetion option to switch this off=
  =
in a future version of SQL Anywhere in the  =
sybase.public.sqlanywhere.product_futures_discussion newsgroup?
Or, thinking about this a moment, it might be another possibility to ado=
pt  =
the C# verbatim string syntax in a future SQL Anywhere version and use  =
something like @'abc\nmo' to get the same result as 'abc\\nmo' currently=
..  =
This would at least be much easier to read and write for Windows path  =
names in strings.
Frank

On Tue, 29 Apr 2008 10:17:41 +0200, Clive Collie  =
<clive_doesnt_like_spam@dillistone.com> wrote:
> v10.01
>
> I updated a table in ISQL and in my app along the lines of
>
> UPDATE "people" SET "col"=3D'abc\nmo' etc
>
> then "select cast(col as binary) etc" gives
>
> [97, 98, 99, 10, 109, 111] - i.e. the \n was changed to new line  =
> character
>
> While
> UPDATE "people" SET "col"=3D'abc\nmo\t12\r34' ...;
>
> gives
>
> abc
> mo\t12\r34
>
> The tab and carriage return are not interprted C-style; just the \n. S=
o  =
> why
> is the \n? When did this happen? Why does this happen? Can I turn this=
> behaviour off ? Yes I can escape it with another \ but that doesn't  =
> really
> help at this stage. When did the DB start talking C?
>
> Thanks
> Clive
>
>
0
Frank
4/29/2008 9:21:15 AM
Just to add:
The 10.0.1 docs are not very clear with string literals and escapes (IMHO):
They list and explain the following char(s) as examples that are treated
specially but do not state if the list is complete. But according to Breck's
book the list *is* complete:
* \n as new line (but not \N)
* \xNN and \XNN as hex values
* \\ as backslash
* '' as single quote
Note that this list differs from C-string escapes.
I agree that now and then this special treatment of '\n' comes as a
surprise. Struggling with doubled backslashes and quotes seems more familiar
:)
Volker
"Frank Ploessel" <fpl...@d_e.i_m_s_h_e_a_l_t_h.c_o_m> wrote in
news:op.uac79luzj0bybf@bonw00164.internal.imsglobal.com...
Clive,
The \n being a newline in char literals is the behavior of SQL Anywhere at
least since version 5. I am not aware of an option or something like this
to switch this behavior off.
Maybe it would be worth to ask for a connetion option to switch this off
in a future version of SQL Anywhere in the
sybase.public.sqlanywhere.product_futures_discussion newsgroup?
Or, thinking about this a moment, it might be another possibility to adopt
the C# verbatim string syntax in a future SQL Anywhere version and use
something like @'abc\nmo' to get the same result as 'abc\\nmo' currently.
This would at least be much easier to read and write for Windows path
names in strings.
Frank

On Tue, 29 Apr 2008 10:17:41 +0200, Clive Collie
<clive_doesnt_like_spam@dillistone.com> wrote:
> v10.01
>
> I updated a table in ISQL and in my app along the lines of
>
> UPDATE "people" SET "col"='abc\nmo' etc
>
> then "select cast(col as binary) etc" gives
>
> [97, 98, 99, 10, 109, 111] - i.e. the \n was changed to new line
> character
>
> While
> UPDATE "people" SET "col"='abc\nmo\t12\r34' ...;
>
> gives
>
> abc
> mo\t12\r34
>
> The tab and carriage return are not interprted C-style; just the \n. So
> why
> is the \n? When did this happen? Why does this happen? Can I turn this
> behaviour off ? Yes I can escape it with another \ but that doesn't
> really
> help at this stage. When did the DB start talking C?
>
> Thanks
> Clive
>
>

0
Volker
4/29/2008 10:32:34 AM
You a right about it being a surprise. I have been using the DB from 5 with 
Powerbuilder for years and never noticed. I was wondering if typing \n into 
a PB front end was somehow masking the problem in the depths of PB 
somewhere. If not how have I been so asleep for so many years?
Or was there perhaps some setting somewhere that sorted out the problem that 
is no longer present or that I have removed by accident.
Clive.
"Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> wrote in message 
news:4816f942$1@forums-1-dub...
> Just to add:
>
> The 10.0.1 docs are not very clear with string literals and escapes 
> (IMHO):
> They list and explain the following char(s) as examples that are treated
> specially but do not state if the list is complete. But according to 
> Breck's
> book the list *is* complete:
> * \n as new line (but not \N)
> * \xNN and \XNN as hex values
> * \\ as backslash
> * '' as single quote
>
> Note that this list differs from C-string escapes.
>
> I agree that now and then this special treatment of '\n' comes as a
> surprise. Struggling with doubled backslashes and quotes seems more 
> familiar
> :)
>
> Volker
>
> "Frank Ploessel" <fpl...@d_e.i_m_s_h_e_a_l_t_h.c_o_m> wrote in
> news:op.uac79luzj0bybf@bonw00164.internal.imsglobal.com...
> Clive,
>
> The \n being a newline in char literals is the behavior of SQL Anywhere at
> least since version 5. I am not aware of an option or something like this
> to switch this behavior off.
>
> Maybe it would be worth to ask for a connetion option to switch this off
> in a future version of SQL Anywhere in the
> sybase.public.sqlanywhere.product_futures_discussion newsgroup?
> Or, thinking about this a moment, it might be another possibility to adopt
> the C# verbatim string syntax in a future SQL Anywhere version and use
> something like @'abc\nmo' to get the same result as 'abc\\nmo' currently.
> This would at least be much easier to read and write for Windows path
> names in strings.
>
> Frank
>
>
> On Tue, 29 Apr 2008 10:17:41 +0200, Clive Collie
> <clive_doesnt_like_spam@dillistone.com> wrote:
>
>> v10.01
>>
>> I updated a table in ISQL and in my app along the lines of
>>
>> UPDATE "people" SET "col"='abc\nmo' etc
>>
>> then "select cast(col as binary) etc" gives
>>
>> [97, 98, 99, 10, 109, 111] - i.e. the \n was changed to new line
>> character
>>
>> While
>> UPDATE "people" SET "col"='abc\nmo\t12\r34' ...;
>>
>> gives
>>
>> abc
>> mo\t12\r34
>>
>> The tab and carriage return are not interprted C-style; just the \n. So
>> why
>> is the \n? When did this happen? Why does this happen? Can I turn this
>> behaviour off ? Yes I can escape it with another \ but that doesn't
>> really
>> help at this stage. When did the DB start talking C?
>>
>> Thanks
>> Clive
>>
>>
>
> 

0
Clive
4/29/2008 1:45:37 PM
Hello,
Actually, what I came across with a colleague just today was that  =
appearantly ASA 10.0.1 seems to interpret the \n notation even within ho=
st  =
variables via ODBC which I think was not the case in earlier releases.
So, executing
UPDATE "people" SET "col"=3D'abc\nmo'
was interpreting the \n as newline in old and new versions, while  =
executing from PowerBuilder via ODBC
STRING ls_val
ls_val =3D 'abc\nmo'
UPDATE "people" SET "col"=3D:ls_val;
was interpreting the \n as a backslash followed by a character n in  =
previous versions. And this seems to have changed in a recent version (w=
e  =
are using 10.0.1.3662).
Frank

On Tue, 29 Apr 2008 15:45:37 +0200, Clive Collie  =
<clive_doesnt_like_spam@dillistone.com> wrote:
> You a right about it being a surprise. I have been using the DB from 5=
  =
> with
> Powerbuilder for years and never noticed. I was wondering if typing \n=
  =
> into
> a PB front end was somehow masking the problem in the depths of PB
> somewhere. If not how have I been so asleep for so many years?
>
> Or was there perhaps some setting somewhere that sorted out the proble=
m  =
> that
> is no longer present or that I have removed by accident.
>
> Clive.
>
> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> wrote in message
> news:4816f942$1@forums-1-dub...
>> Just to add:
>>
>> The 10.0.1 docs are not very clear with string literals and escapes
>> (IMHO):
>> They list and explain the following char(s) as examples that are trea=
ted
>> specially but do not state if the list is complete. But according to
>> Breck's
>> book the list *is* complete:
>> * \n as new line (but not \N)
>> * \xNN and \XNN as hex values
>> * \\ as backslash
>> * '' as single quote
>>
>> Note that this list differs from C-string escapes.
>>
>> I agree that now and then this special treatment of '\n' comes as a
>> surprise. Struggling with doubled backslashes and quotes seems more
>> familiar
>> :)
>>
>> Volker
>>
>> "Frank Ploessel" <fpl...@d_e.i_m_s_h_e_a_l_t_h.c_o_m> wrote in
>> news:op.uac79luzj0bybf@bonw00164.internal.imsglobal.com...
>> Clive,
>>
>> The \n being a newline in char literals is the behavior of SQL Anywhe=
re  =
>> at
>> least since version 5. I am not aware of an option or something like =
 =
>> this
>> to switch this behavior off.
>>
>> Maybe it would be worth to ask for a connetion option to switch this =
off
>> in a future version of SQL Anywhere in the
>> sybase.public.sqlanywhere.product_futures_discussion newsgroup?
>> Or, thinking about this a moment, it might be another possibility to =
 =
>> adopt
>> the C# verbatim string syntax in a future SQL Anywhere version and us=
e
>> something like @'abc\nmo' to get the same result as 'abc\\nmo'  =
>> currently.
>> This would at least be much easier to read and write for Windows path=
>> names in strings.
>>
>> Frank
>>
>>
>> On Tue, 29 Apr 2008 10:17:41 +0200, Clive Collie
>> <clive_doesnt_like_spam@dillistone.com> wrote:
>>
>>> v10.01
>>>
>>> I updated a table in ISQL and in my app along the lines of
>>>
>>> UPDATE "people" SET "col"=3D'abc\nmo' etc
>>>
>>> then "select cast(col as binary) etc" gives
>>>
>>> [97, 98, 99, 10, 109, 111] - i.e. the \n was changed to new line
>>> character
>>>
>>> While
>>> UPDATE "people" SET "col"=3D'abc\nmo\t12\r34' ...;
>>>
>>> gives
>>>
>>> abc
>>> mo\t12\r34
>>>
>>> The tab and carriage return are not interprted C-style; just the \n.=
 So
>>> why
>>> is the \n? When did this happen? Why does this happen? Can I turn th=
is
>>> behaviour off ? Yes I can escape it with another \ but that doesn't
>>> really
>>> help at this stage. When did the DB start talking C?
>>>
>>> Thanks
>>> Clive
>>>
>>>
>>
>>
>
>
0
Frank
4/29/2008 4:34:32 PM
Check the PowerBuilder DisableBind setting; it should be 0 to ensure that 
host variables are used. (Disclaimer: I'm not a PB user.)
If that doesn't solve the problem, enable request logging on the server and 
determine if the value is being sent as a host variable or as a string 
literal. If it is being sent as a string literal, the translation of \n to a 
newline character is expected, and there must be some other PB setting to 
control this behavior.
SQL Anywhere Developer Community: 
http://www.sybase.com/developer/library/sql-anywhere-techcorner
SQL Anywhere Blog Center: http://www.sybase.com/sqlanyblogs
"Frank Ploessel" <fpl...@d_e.i_m_s_h_e_a_l_t_h.c_o_m> wrote in message 
news:op.uadsbjztj0bybf@bonw00164.internal.imsglobal.com...
Hello,
Actually, what I came across with a colleague just today was that
appearantly ASA 10.0.1 seems to interpret the \n notation even within host
variables via ODBC which I think was not the case in earlier releases.
So, executing
UPDATE "people" SET "col"='abc\nmo'
was interpreting the \n as newline in old and new versions, while
executing from PowerBuilder via ODBC
STRING ls_val
ls_val = 'abc\nmo'
UPDATE "people" SET "col"=:ls_val;
was interpreting the \n as a backslash followed by a character n in
previous versions. And this seems to have changed in a recent version (we
are using 10.0.1.3662).
Frank

On Tue, 29 Apr 2008 15:45:37 +0200, Clive Collie
<clive_doesnt_like_spam@dillistone.com> wrote:
> You a right about it being a surprise. I have been using the DB from 5 
> with
> Powerbuilder for years and never noticed. I was wondering if typing \n 
> into
> a PB front end was somehow masking the problem in the depths of PB
> somewhere. If not how have I been so asleep for so many years?
>
> Or was there perhaps some setting somewhere that sorted out the problem 
> that
> is no longer present or that I have removed by accident.
>
> Clive.
>
> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> wrote in message
> news:4816f942$1@forums-1-dub...
>> Just to add:
>>
>> The 10.0.1 docs are not very clear with string literals and escapes
>> (IMHO):
>> They list and explain the following char(s) as examples that are treated
>> specially but do not state if the list is complete. But according to
>> Breck's
>> book the list *is* complete:
>> * \n as new line (but not \N)
>> * \xNN and \XNN as hex values
>> * \\ as backslash
>> * '' as single quote
>>
>> Note that this list differs from C-string escapes.
>>
>> I agree that now and then this special treatment of '\n' comes as a
>> surprise. Struggling with doubled backslashes and quotes seems more
>> familiar
>> :)
>>
>> Volker
>>
>> "Frank Ploessel" <fpl...@d_e.i_m_s_h_e_a_l_t_h.c_o_m> wrote in
>> news:op.uac79luzj0bybf@bonw00164.internal.imsglobal.com...
>> Clive,
>>
>> The \n being a newline in char literals is the behavior of SQL Anywhere 
>> at
>> least since version 5. I am not aware of an option or something like 
>> this
>> to switch this behavior off.
>>
>> Maybe it would be worth to ask for a connetion option to switch this off
>> in a future version of SQL Anywhere in the
>> sybase.public.sqlanywhere.product_futures_discussion newsgroup?
>> Or, thinking about this a moment, it might be another possibility to 
>> adopt
>> the C# verbatim string syntax in a future SQL Anywhere version and use
>> something like @'abc\nmo' to get the same result as 'abc\\nmo' 
>> currently.
>> This would at least be much easier to read and write for Windows path
>> names in strings.
>>
>> Frank
>>
>>
>> On Tue, 29 Apr 2008 10:17:41 +0200, Clive Collie
>> <clive_doesnt_like_spam@dillistone.com> wrote:
>>
>>> v10.01
>>>
>>> I updated a table in ISQL and in my app along the lines of
>>>
>>> UPDATE "people" SET "col"='abc\nmo' etc
>>>
>>> then "select cast(col as binary) etc" gives
>>>
>>> [97, 98, 99, 10, 109, 111] - i.e. the \n was changed to new line
>>> character
>>>
>>> While
>>> UPDATE "people" SET "col"='abc\nmo\t12\r34' ...;
>>>
>>> gives
>>>
>>> abc
>>> mo\t12\r34
>>>
>>> The tab and carriage return are not interprted C-style; just the \n. So
>>> why
>>> is the \n? When did this happen? Why does this happen? Can I turn this
>>> behaviour off ? Yes I can escape it with another \ but that doesn't
>>> really
>>> help at this stage. When did the DB start talking C?
>>>
>>> Thanks
>>> Clive
>>>
>>>
>>
>>
>
>

0
Bruce
4/29/2008 6:11:07 PM
Bruce,
Good point, this may well be the case.
Frank
On Tue, 29 Apr 2008 20:11:07 +0200, Bruce Hay  =
<h_a_y~a_t~i_a_n_y_w_h_e_r_e~d_o_t~c_o_m> wrote:
> Check the PowerBuilder DisableBind setting; it should be 0 to ensure t=
hat
> host variables are used. (Disclaimer: I'm not a PB user.)
>
> If that doesn't solve the problem, enable request logging on the serve=
r  =
> and
> determine if the value is being sent as a host variable or as a string=
> literal. If it is being sent as a string literal, the translation of \=
n  =
> to a
> newline character is expected, and there must be some other PB setting=
 to
> control this behavior.
>
> SQL Anywhere Developer Community:
> http://www.sybase.com/developer/library/sql-anywhere-techcorner
> SQL Anywhere Blog Center: http://www.sybase.com/sqlanyblogs
>
> "Frank Ploessel" <fpl...@d_e.i_m_s_h_e_a_l_t_h.c_o_m> wrote in message=
> news:op.uadsbjztj0bybf@bonw00164.internal.imsglobal.com...
> Hello,
>
> Actually, what I came across with a colleague just today was that
> appearantly ASA 10.0.1 seems to interpret the \n notation even within =
 =
> host
> variables via ODBC which I think was not the case in earlier releases.=
>
> So, executing
>
> UPDATE "people" SET "col"=3D'abc\nmo'
>
> was interpreting the \n as newline in old and new versions, while
> executing from PowerBuilder via ODBC
>
> STRING ls_val
> ls_val =3D 'abc\nmo'
> UPDATE "people" SET "col"=3D:ls_val;
>
> was interpreting the \n as a backslash followed by a character n in
> previous versions. And this seems to have changed in a recent version =
(we
> are using 10.0.1.3662).
>
> Frank
>
>
> On Tue, 29 Apr 2008 15:45:37 +0200, Clive Collie
> <clive_doesnt_like_spam@dillistone.com> wrote:
>
>> You a right about it being a surprise. I have been using the DB from =
5
>> with
>> Powerbuilder for years and never noticed. I was wondering if typing \=
n
>> into
>> a PB front end was somehow masking the problem in the depths of PB
>> somewhere. If not how have I been so asleep for so many years?
>>
>> Or was there perhaps some setting somewhere that sorted out the probl=
em
>> that
>> is no longer present or that I have removed by accident.
>>
>> Clive.
>>
>> "Volker Barth" <No_VBarth@Spam_GLOBAL-FINANZ.de> wrote in message
>> news:4816f942$1@forums-1-dub...
>>> Just to add:
>>>
>>> The 10.0.1 docs are not very clear with string literals and escapes
>>> (IMHO):
>>> They list and explain the following char(s) as examples that are  =
>>> treated
>>> specially but do not state if the list is complete. But according to=
>>> Breck's
>>> book the list *is* complete:
>>> * \n as new line (but not \N)
>>> * \xNN and \XNN as hex values
>>> * \\ as backslash
>>> * '' as single quote
>>>
>>> Note that this list differs from C-string escapes.
>>>
>>> I agree that now and then this special treatment of '\n' comes as a
>>> surprise. Struggling with doubled backslashes and quotes seems more
>>> familiar
>>> :)
>>>
>>> Volker
>>>
>>> "Frank Ploessel" <fpl...@d_e.i_m_s_h_e_a_l_t_h.c_o_m> wrote in
>>> news:op.uac79luzj0bybf@bonw00164.internal.imsglobal.com...
>>> Clive,
>>>
>>> The \n being a newline in char literals is the behavior of SQL Anywh=
ere
>>> at
>>> least since version 5. I am not aware of an option or something like=
>>> this
>>> to switch this behavior off.
>>>
>>> Maybe it would be worth to ask for a connetion option to switch this=
  =
>>> off
>>> in a future version of SQL Anywhere in the
>>> sybase.public.sqlanywhere.product_futures_discussion newsgroup?
>>> Or, thinking about this a moment, it might be another possibility to=
>>> adopt
>>> the C# verbatim string syntax in a future SQL Anywhere version and u=
se
>>> something like @'abc\nmo' to get the same result as 'abc\\nmo'
>>> currently.
>>> This would at least be much easier to read and write for Windows pat=
h
>>> names in strings.
>>>
>>> Frank
>>>
>>>
>>> On Tue, 29 Apr 2008 10:17:41 +0200, Clive Collie
>>> <clive_doesnt_like_spam@dillistone.com> wrote:
>>>
>>>> v10.01
>>>>
>>>> I updated a table in ISQL and in my app along the lines of
>>>>
>>>> UPDATE "people" SET "col"=3D'abc\nmo' etc
>>>>
>>>> then "select cast(col as binary) etc" gives
>>>>
>>>> [97, 98, 99, 10, 109, 111] - i.e. the \n was changed to new line
>>>> character
>>>>
>>>> While
>>>> UPDATE "people" SET "col"=3D'abc\nmo\t12\r34' ...;
>>>>
>>>> gives
>>>>
>>>> abc
>>>> mo\t12\r34
>>>>
>>>> The tab and carriage return are not interprted C-style; just the \n=
..  =
>>>> So
>>>> why
>>>> is the \n? When did this happen? Why does this happen? Can I turn t=
his
>>>> behaviour off ? Yes I can escape it with another \ but that doesn't=
>>>> really
>>>> help at this stage. When did the DB start talking C?
>>>>
>>>> Thanks
>>>> Clive
>>>>
>>>>
>>>
>>>
>>
>>
>
>
0
Frank
4/30/2008 5:12:22 PM
Reply: