Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Enhance the str function

11 posts in Product Futures Discussion Last posting was on 2002-08-16 20:42:27.0Z
Carl Kayser Posted on 2002-05-09 14:47:03.0Z
From: "Carl Kayser" <kayser_c@bls.gov>
Subject: Enhance the str function
Date: Thu, 9 May 2002 10:47:03 -0400
Lines: 17
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID: <MUWA$m29BHA.270@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: 146.142.35.25
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:497
Article PK: 93666

I find it to be very useful to list "long" numbers comma-separated. It's
easier to see the scale difference between 1,234,567 and 1234567. Consider
the "per sec", etc. outputs from sp_sysmon as a specific example. Currently
I use the awkward

substring (convert (char (N+3), convert (money, <ARG>, 1), 1, N)

in order to get an N-length string with commas for cardinal numbers. I'd
like to do:

str (<ARG>, N, 0, 1)

where the last argument of 1 indicates "comma-separate the output". The
default value would be 0 and would mean "do not comma-separate the output".
If "decimal" is non-zero the decimal portion would never be comma-separated.


kevin.mcginn Posted on 2002-08-16 20:42:27.0Z
From: kevin.mcginn@baesystems.com
Date: Fri, 16 Aug 2002 16:42:27 -0400
Newsgroups: sybase.public.ase.product_futures_discussion
Subject: Re: Enhance the str function
Message-ID: <FBE6B1B5688217A10071C00985256C17.0057792B85256BB4@webforums>
References: <MUWA$m29BHA.270@forums.sybase.com>
Lines: 7
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com!webforums.sybase.com!news
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:316
Article PK: 93485

This level of functionality and flexibility can readily be achieved by
writting a static Java class. This would allow creating any number of
static polymorphic methods that would produce the string in any number of
variable formats. From the locale information available through Java
methods decisions could be made as to formatting techniques and the like

Kevin McGinn


Carl Kayser Posted on 2002-05-12 13:54:08.0Z
From: "Carl Kayser" <kayser_c@bls.gov>
References: <MUWA$m29BHA.270@forums.sybase.com>
Subject: Re: Enhance the str function
Date: Sun, 12 May 2002 09:54:08 -0400
Lines: 47
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID: <kIfOP3b#BHA.232@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: 146.142.35.25
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:489
Article PK: 93655

Roger and Michael make a very good point with regards to locales issues.
The best that I can say is that the problem would also exist with the
convert function as described at the bottom as well. We would be no worse
off. BTW does this issue also exist with the convert function?

Anthony also makes a very good point about display being the function of the
client. However isql is what I usually use. Should I replace it with a
GUI? Well, some of them are third-party tools and the source code is not
available for tweaking. Although the various sp_help procs can be executed
from various front-ends I think that it is fairly common for them to be
executed from isql. In which case ...? The same applies to sp_sysmon.
Again, Anthony's point is a good one that makes a lot of sense but it seems
to really limit isql. BTW does sqsh have the ability to do this formatting?

Eugene's comment about FORMAT begs the question "What is the FORMAT
function?". If it is a general formatting function then I take Anthony's
viewpoint. I'm not interested in converting "I am here" to "I a,m h,ere" or
the like. My guess is that FORMAT accepts various inputs whereas str
accepts numeric inputs which is what I want to format. I imagine that the
FORMAT solution could also go down the "Oracle bloatware" path.

"Carl Kayser" <kayser_c@bls.gov> wrote in message
news:MUWA$m29BHA.270@forums.sybase.com...
> I find it to be very useful to list "long" numbers comma-separated. It's
> easier to see the scale difference between 1,234,567 and 1234567.
Consider
> the "per sec", etc. outputs from sp_sysmon as a specific example.
Currently
> I use the awkward
>
> substring (convert (char (N+3), convert (money, <ARG>, 1), 1, N)
>
> in order to get an N-length string with commas for cardinal numbers. I'd
> like to do:
>
> str (<ARG>, N, 0, 1)
>
> where the last argument of 1 indicates "comma-separate the output". The
> default value would be 0 and would mean "do not comma-separate the
output".
> If "decimal" is non-zero the decimal portion would never be
comma-separated.
>
>


Anthony Mandic Posted on 2002-05-13 09:05:23.0Z
Message-ID: <3CDF81D3.72E32E22@start.com.au>
Date: Mon, 13 May 2002 19:05:23 +1000
From: Anthony Mandic <sp_am_block@start.com.au>
Organization: Mandic Consulting Pty. Ltd.
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Enhance the str function
References: <MUWA$m29BHA.270@forums.sybase.com> <kIfOP3b#BHA.232@forums.sybase.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Newsgroups: sybase.public.ase.product_futures_discussion
Lines: 54
NNTP-Posting-Host: 203.3.176.10
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:486
Article PK: 93653


Carl Kayser wrote:
>
> Roger and Michael make a very good point with regards to locales issues.
> The best that I can say is that the problem would also exist with the
> convert function as described at the bottom as well. We would be no worse
> off. BTW does this issue also exist with the convert function?
>
> Anthony also makes a very good point about display being the function of the
> client. However isql is what I usually use.

I'm not overly keen on using isql to display data due to its
limited functionality in that regard. However, it should be
using the locales so, if the locales support decimal formatting,
then it should work fine. However, a quick perusal didn't show
up anything obvious, so you may be out of luck.

> Should I replace it with a GUI?

That would be my choice for interactive data display. You can
try SQL Advantage if you like but it doesn't support this style
of formatting (what I usually do is select with the mouse over
3 digits to help differentiate the data but that's really just
a kludge).

> Well, some of them are third-party tools and the source code is not
> available for tweaking. Although the various sp_help procs can be executed
> from various front-ends I think that it is fairly common for them to be
> executed from isql. In which case ...? The same applies to sp_sysmon.
> Again, Anthony's point is a good one that makes a lot of sense but it seems
> to really limit isql. BTW does sqsh have the ability to do this formatting?

I'm not sure but the source code is available. If you felt up
to it you could try and modify it yourself.

> Eugene's comment about FORMAT begs the question "What is the FORMAT
> function?". If it is a general formatting function then I take Anthony's
> viewpoint. I'm not interested in converting "I am here" to "I a,m h,ere" or
> the like. My guess is that FORMAT accepts various inputs whereas str
> accepts numeric inputs which is what I want to format. I imagine that the
> FORMAT solution could also go down the "Oracle bloatware" path.

I'm not sure what this is. Its not T-SQL.

-am © 2002


Roger Broadbent Posted on 2002-05-13 13:04:56.0Z
From: "Roger Broadbent" <RBroadbent@wilco-int.excise-this.com>
References: <MUWA$m29BHA.270@forums.sybase.com> <kIfOP3b#BHA.232@forums.sybase.com> <3CDF81D3.72E32E22@start.com.au>
Subject: Re: Enhance the str function
Date: Mon, 13 May 2002 14:04:56 +0100
Lines: 71
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <pf$BRCo#BHA.232@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: wilcohost-180.wilco-int.com 212.36.174.180
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:484
Article PK: 93651

The trouble with putting such client-side functions in the core server is
that people will use them, then complain about the known and inbuilt
limitations. If Sybase were to implement your proposal, there would be calls
for it to be aware of the client locale.

Updating sqsh to do what you want sounds like the best idea to me.

--
Roger Broadbent
Technical Consultant
Wilco International Ltd

NOTE: Anti-Spam measures taken due to excessive spam levels generated
recently through this newsgroup.

Anthony Mandic <sp_am_block@start.com.au> wrote in message
news:3CDF81D3.72E32E22@start.com.au...
> Carl Kayser wrote:
> >
> > Roger and Michael make a very good point with regards to locales issues.
> > The best that I can say is that the problem would also exist with the
> > convert function as described at the bottom as well. We would be no
worse
> > off. BTW does this issue also exist with the convert function?
> >
> > Anthony also makes a very good point about display being the function of
the
> > client. However isql is what I usually use.
>
> I'm not overly keen on using isql to display data due to its
> limited functionality in that regard. However, it should be
> using the locales so, if the locales support decimal formatting,
> then it should work fine. However, a quick perusal didn't show
> up anything obvious, so you may be out of luck.
>
> > Should I replace it with a GUI?
>
> That would be my choice for interactive data display. You can
> try SQL Advantage if you like but it doesn't support this style
> of formatting (what I usually do is select with the mouse over
> 3 digits to help differentiate the data but that's really just
> a kludge).
>
> > Well, some of them are third-party tools and the source code is not
> > available for tweaking. Although the various sp_help procs can be
executed
> > from various front-ends I think that it is fairly common for them to be
> > executed from isql. In which case ...? The same applies to sp_sysmon.
> > Again, Anthony's point is a good one that makes a lot of sense but it
seems
> > to really limit isql. BTW does sqsh have the ability to do this
formatting?
>
> I'm not sure but the source code is available. If you felt up
> to it you could try and modify it yourself.
>
> > Eugene's comment about FORMAT begs the question "What is the FORMAT
> > function?". If it is a general formatting function then I take
Anthony's
> > viewpoint. I'm not interested in converting "I am here" to "I a,m
h,ere" or
> > the like. My guess is that FORMAT accepts various inputs whereas str
> > accepts numeric inputs which is what I want to format. I imagine that
the
> > FORMAT solution could also go down the "Oracle bloatware" path.
>
> I'm not sure what this is. Its not T-SQL.
>
> -am © 2002


Michael Peppler Posted on 2002-05-13 14:39:09.0Z
From: Michael Peppler <mpeppler@peppler.org>
Subject: Re: Enhance the str function
Date: Mon, 13 May 2002 07:39:09 -0700
References: <MUWA$m29BHA.270@forums.sybase.com> <kIfOP3b#BHA.232@forums.sybase.com> <3CDF81D3.72E32E22@start.com.au> <pf$BRCo#BHA.232@forums.sybase.com>
User-Agent: Pan/0.11.2 (Unix)
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Comment-To: "Roger Broadbent" <RBroadbent@wilco-int.excise-this.com>
Message-ID: <q26LB1o#BHA.232@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
Lines: 129
NNTP-Posting-Host: gw.peppler.org 206.55.243.57
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com!not-for-mail
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:483
Article PK: 93652

I played around with this with both isql and sqsh last night, and to a
certain extent the server becomes aware of your locale when you set the
"language" parameter (i.e use the -z flag, or set LANG or LC_ALL).

sqsh and isql behave slightly differently in this situation:

plum (7:30AM):1 > isql -Usa -P -Splum -z french
1> select getdate()
2> go

--------------------------
13/05/02

(1 row affected)

plum (7:31AM):2 > sqsh -Usa -P -Splum -z french
sqsh-1.5.2 Copyright (C) 1995, 1996 Scott C. Gray
This is free software with ABSOLUTELY NO WARRANTY
For more information type '\warranty'
[21] plum.master: 1> select getdate()
[21] plum.master: 2> go

-------------------
May 13 2002 7:31AM

(1 row affected)

OK - this formatting difference was done in the client.
The isql default date formatting for the "french" locale is correct, in t
the sense that it is dd/mm/yyyy, but the time portion is dropped
completely. This feels like a bug to me.

sqsh on the other hand ignores this completely - and *that* feels like a
bug as well (although it's an old version of sqsh on this box - maybe 2.1
does the right thing.)

Now if we execute a convert() on the server, we get:

1> select convert(varchar, getdate(), 109)
2> go

------------------------------
mai 13 2002 7:32:54:323AM

(1 row affected)

The month name is localized based on the client language setting.
But the date format isn't really localized (i.e. it's still mmm dd yyyy
which isn't what would be used in Europe).

So maybe it isn't impossible to get the correct behavior in the server
(which doesn't mean that it's necessarily a good idea - I tend to agree
that the server should do computing work - display issues should be left
in to the client).

Michael

On Mon, 13 May 2002 06:04:56 -0700, Roger Broadbent wrote:

> The trouble with putting such client-side functions in the core server
> is that people will use them, then complain about the known and inbuilt
> limitations. If Sybase were to implement your proposal, there would be
> calls for it to be aware of the client locale.
>
> Updating sqsh to do what you want sounds like the best idea to me.
>
> --
> Roger Broadbent
> Technical Consultant
> Wilco International Ltd
>
> NOTE: Anti-Spam measures taken due to excessive spam levels generated
> recently through this newsgroup.
>
> Anthony Mandic <sp_am_block@start.com.au> wrote in message
> news:3CDF81D3.72E32E22@start.com.au...
>> Carl Kayser wrote:
>> >
>> > Roger and Michael make a very good point with regards to locales
>> > issues. The best that I can say is that the problem would also exist
>> > with the convert function as described at the bottom as well. We
>> > would be no
> worse
>> > off. BTW does this issue also exist with the convert function?
>> >
>> > Anthony also makes a very good point about display being the function
>> > of
> the
>> > client. However isql is what I usually use.
>>
>> I'm not overly keen on using isql to display data due to its limited
>> functionality in that regard. However, it should be using the locales
>> so, if the locales support decimal formatting, then it should work
>> fine. However, a quick perusal didn't show up anything obvious, so you
>> may be out of luck.
>>
>> > Should I replace it with a GUI?
>>
>> That would be my choice for interactive data display. You can try SQL
>> Advantage if you like but it doesn't support this style of formatting
>> (what I usually do is select with the mouse over 3 digits to help
>> differentiate the data but that's really just a kludge).
>>
>> > Well, some of them are third-party tools and the source code is not
>> > available for tweaking. Although the various sp_help procs can be
> executed
>> > from various front-ends I think that it is fairly common for them to
>> > be executed from isql. In which case ...? The same applies to
>> > sp_sysmon. Again, Anthony's point is a good one that makes a lot of
>> > sense but it
> seems
>> > to really limit isql. BTW does sqsh have the ability to do this
> formatting?
>>
>> I'm not sure but the source code is available. If you felt up to it you
>> could try and modify it yourself.
>>
>> > Eugene's comment about FORMAT begs the question "What is the FORMAT
>> > function?". If it is a general formatting function then I take
> Anthony's
>> > viewpoint. I'm not interested in converting "I am here" to "I a,m
> h,ere" or
>> > the like. My guess is that FORMAT accepts various inputs whereas str
>> > accepts numeric inputs which is what I want to format. I imagine
>> > that
> the
>> > FORMAT solution could also go down the "Oracle bloatware" path.
>>
>> I'm not sure what this is. Its not T-SQL.
>>
>> -am © 2002

--
Michael Peppler Data Migrations, Inc.
mpeppler@peppler.org *or* mpeppler@mbay.net
http://www.mbay.net/~mpeppler
International Sybase User Group: http://www.isug.com


Roger Broadbent Posted on 2002-05-13 15:54:34.0Z
From: "Roger Broadbent" <RBroadbent@wilco-int.excise-this.com>
References: <MUWA$m29BHA.270@forums.sybase.com> <kIfOP3b#BHA.232@forums.sybase.com> <3CDF81D3.72E32E22@start.com.au> <pf$BRCo#BHA.232@forums.sybase.com> <q26LB1o#BHA.232@forums.sybase.com>
Subject: Re: Enhance the str function
Date: Mon, 13 May 2002 16:54:34 +0100
Lines: 153
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <L35aEhp#BHA.131@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: wilcohost-180.wilco-int.com 212.36.174.180
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:482
Article PK: 93650

Interesting result. I had no idea that the server would be aware of the
client's locale like that.

--
Roger Broadbent
Technical Consultant
Wilco International Ltd

NOTE: Anti-Spam measures taken due to excessive spam levels generated
recently through this newsgroup.

Michael Peppler <mpeppler@peppler.org> wrote in message
news:q26LB1o#BHA.232@forums.sybase.com...
> I played around with this with both isql and sqsh last night, and to a
> certain extent the server becomes aware of your locale when you set the
> "language" parameter (i.e use the -z flag, or set LANG or LC_ALL).
>
> sqsh and isql behave slightly differently in this situation:
>
> plum (7:30AM):1 > isql -Usa -P -Splum -z french
> 1> select getdate()
> 2> go
>
> --------------------------
> 13/05/02
>
> (1 row affected)
>
> plum (7:31AM):2 > sqsh -Usa -P -Splum -z french
> sqsh-1.5.2 Copyright (C) 1995, 1996 Scott C. Gray
> This is free software with ABSOLUTELY NO WARRANTY
> For more information type '\warranty'
> [21] plum.master: 1> select getdate()
> [21] plum.master: 2> go
>
> -------------------
> May 13 2002 7:31AM
>
> (1 row affected)
>
> OK - this formatting difference was done in the client.
> The isql default date formatting for the "french" locale is correct, in t
> the sense that it is dd/mm/yyyy, but the time portion is dropped
> completely. This feels like a bug to me.
>
> sqsh on the other hand ignores this completely - and *that* feels like a
> bug as well (although it's an old version of sqsh on this box - maybe 2.1
> does the right thing.)
>
> Now if we execute a convert() on the server, we get:
>
> 1> select convert(varchar, getdate(), 109)
> 2> go
>
> ------------------------------
> mai 13 2002 7:32:54:323AM
>
> (1 row affected)
>
> The month name is localized based on the client language setting.
> But the date format isn't really localized (i.e. it's still mmm dd yyyy
> which isn't what would be used in Europe).
>
> So maybe it isn't impossible to get the correct behavior in the server
> (which doesn't mean that it's necessarily a good idea - I tend to agree
> that the server should do computing work - display issues should be left
> in to the client).
>
> Michael
>
>
> On Mon, 13 May 2002 06:04:56 -0700, Roger Broadbent wrote:
>
> > The trouble with putting such client-side functions in the core server
> > is that people will use them, then complain about the known and inbuilt
> > limitations. If Sybase were to implement your proposal, there would be
> > calls for it to be aware of the client locale.
> >
> > Updating sqsh to do what you want sounds like the best idea to me.
> >
> > --
> > Roger Broadbent
> > Technical Consultant
> > Wilco International Ltd
> >
> > NOTE: Anti-Spam measures taken due to excessive spam levels generated
> > recently through this newsgroup.
> >
> > Anthony Mandic <sp_am_block@start.com.au> wrote in message
> > news:3CDF81D3.72E32E22@start.com.au...
> >> Carl Kayser wrote:
> >> >
> >> > Roger and Michael make a very good point with regards to locales
> >> > issues. The best that I can say is that the problem would also exist
> >> > with the convert function as described at the bottom as well. We
> >> > would be no
> > worse
> >> > off. BTW does this issue also exist with the convert function?
> >> >
> >> > Anthony also makes a very good point about display being the function
> >> > of
> > the
> >> > client. However isql is what I usually use.
> >>
> >> I'm not overly keen on using isql to display data due to its limited
> >> functionality in that regard. However, it should be using the locales
> >> so, if the locales support decimal formatting, then it should work
> >> fine. However, a quick perusal didn't show up anything obvious, so you
> >> may be out of luck.
> >>
> >> > Should I replace it with a GUI?
> >>
> >> That would be my choice for interactive data display. You can try SQL
> >> Advantage if you like but it doesn't support this style of formatting
> >> (what I usually do is select with the mouse over 3 digits to help
> >> differentiate the data but that's really just a kludge).
> >>
> >> > Well, some of them are third-party tools and the source code is not
> >> > available for tweaking. Although the various sp_help procs can be
> > executed
> >> > from various front-ends I think that it is fairly common for them to
> >> > be executed from isql. In which case ...? The same applies to
> >> > sp_sysmon. Again, Anthony's point is a good one that makes a lot of
> >> > sense but it
> > seems
> >> > to really limit isql. BTW does sqsh have the ability to do this
> > formatting?
> >>
> >> I'm not sure but the source code is available. If you felt up to it you
> >> could try and modify it yourself.
> >>
> >> > Eugene's comment about FORMAT begs the question "What is the FORMAT
> >> > function?". If it is a general formatting function then I take
> > Anthony's
> >> > viewpoint. I'm not interested in converting "I am here" to "I a,m
> > h,ere" or
> >> > the like. My guess is that FORMAT accepts various inputs whereas str
> >> > accepts numeric inputs which is what I want to format. I imagine
> >> > that
> > the
> >> > FORMAT solution could also go down the "Oracle bloatware" path.
> >>
> >> I'm not sure what this is. Its not T-SQL.
> >>
> >> -am © 2002
>
> --
> Michael Peppler Data Migrations, Inc.
> mpeppler@peppler.org *or* mpeppler@mbay.net
> http://www.mbay.net/~mpeppler
> International Sybase User Group: http://www.isug.com


Anthony Mandic Posted on 2002-05-10 09:43:26.0Z
Message-ID: <3CDB963E.B1924141@start.com.au>
Date: Fri, 10 May 2002 19:43:26 +1000
From: Anthony Mandic <sp_am_block@start.com.au>
Organization: Mandic Consulting Pty. Ltd.
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Enhance the str function
References: <MUWA$m29BHA.270@forums.sybase.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Newsgroups: sybase.public.ase.product_futures_discussion
Lines: 11
NNTP-Posting-Host: 203.3.176.10
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:493
Article PK: 93661


Carl Kayser wrote:
>
> I find it to be very useful to list "long" numbers comma-separated. It's
> easier to see the scale difference between 1,234,567 and 1234567. Consider
> the "per sec", etc. outputs from sp_sysmon as a specific example.

Display is a function of the client. So the best thing to do
would be to find a client that supports comma-separated display
of numerical values.

-am © 2002


Eugene Korolkov Posted on 2002-05-09 18:38:25.0Z
Message-ID: <3CDAC220.5D340562@dgny.com>
Date: Thu, 09 May 2002 14:38:25 -0400
From: Eugene Korolkov <ekorolkov@dgny.com>
Organization: The Davidsohn Group
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Carl Kayser <kayser_c@bls.gov>
Subject: Re: Enhance the str function
References: <MUWA$m29BHA.270@forums.sybase.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.ase.product_futures_discussion
Lines: 22
NNTP-Posting-Host: 12.3.91.29
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:494
Article PK: 93662

Why just not to require implementing FORMAT command,
like Oracle does in sqlplus or any other decent lang./tool has?

Eugene

Carl Kayser wrote:

> I find it to be very useful to list "long" numbers comma-separated. It's
> easier to see the scale difference between 1,234,567 and 1234567. Consider
> the "per sec", etc. outputs from sp_sysmon as a specific example. Currently
> I use the awkward
>
> substring (convert (char (N+3), convert (money, <ARG>, 1), 1, N)
>
> in order to get an N-length string with commas for cardinal numbers. I'd
> like to do:
>
> str (<ARG>, N, 0, 1)
>
> where the last argument of 1 indicates "comma-separate the output". The
> default value would be 0 and would mean "do not comma-separate the output".
> If "decimal" is non-zero the decimal portion would never be comma-separated.


Michael Peppler Posted on 2002-05-09 15:55:16.0Z
From: Michael Peppler <mpeppler@peppler.org>
Subject: Re: Enhance the str function
Date: Thu, 09 May 2002 08:55:16 -0700
References: <MUWA$m29BHA.270@forums.sybase.com>
User-Agent: Pan/0.11.2 (Unix)
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Comment-To: "Carl Kayser" <kayser_c@bls.gov>
Message-ID: <e205zM39BHA.130@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
Lines: 34
NNTP-Posting-Host: gw.peppler.org 206.55.243.57
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com!not-for-mail
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:495
Article PK: 93664

It's a great idea - but like Roger my first reaction was that it'd have
to be locale aware which shouldn't really be that difficult.

However it would always end up using the locale of the server, rather
than that of the client, which would cause "incorrect" results if the
client and the server run on completely different locales.

Michael

On Thu, 09 May 2002 07:47:03 -0700, Carl Kayser wrote:

> I find it to be very useful to list "long" numbers comma-separated. It's
> easier to see the scale difference between 1,234,567 and 1234567.
> Consider the "per sec", etc. outputs from sp_sysmon as a specific
> example. Currently I use the awkward
>
> substring (convert (char (N+3), convert (money, <ARG>, 1), 1, N)
>
> in order to get an N-length string with commas for cardinal numbers. I'd
> like to do:
>
> str (<ARG>, N, 0, 1)
>
> where the last argument of 1 indicates "comma-separate the output". The
> default value would be 0 and would mean "do not comma-separate the
> output". If "decimal" is non-zero the decimal portion would never be
> comma-separated.

--
Michael Peppler Data Migrations, Inc.
mpeppler@peppler.org *or* mpeppler@mbay.net
http://www.mbay.net/~mpeppler
International Sybase User Group: http://www.isug.com


Roger Broadbent Posted on 2002-05-09 15:28:36.0Z
From: "Roger Broadbent" <RBroadbent@wilco-int.excise-this.com>
References: <MUWA$m29BHA.270@forums.sybase.com>
Subject: Re: Enhance the str function
Date: Thu, 9 May 2002 16:28:36 +0100
Lines: 36
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <d1247$29BHA.131@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: wilcohost-180.wilco-int.com 212.36.174.180
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:496
Article PK: 93665

This would have to be locale aware; some locales use "." for the thousands
separator and "," for the decimal point.

--
Roger Broadbent
Technical Consultant
Wilco International Ltd

NOTE: Anti-Spam measures taken due to excessive spam levels generated
recently through this newsgroup.

Carl Kayser <kayser_c@bls.gov> wrote in message
news:MUWA$m29BHA.270@forums.sybase.com...
> I find it to be very useful to list "long" numbers comma-separated. It's
> easier to see the scale difference between 1,234,567 and 1234567.
Consider
> the "per sec", etc. outputs from sp_sysmon as a specific example.
Currently
> I use the awkward
>
> substring (convert (char (N+3), convert (money, <ARG>, 1), 1, N)
>
> in order to get an N-length string with commas for cardinal numbers. I'd
> like to do:
>
> str (<ARG>, N, 0, 1)
>
> where the last argument of 1 indicates "comma-separate the output". The
> default value would be 0 and would mean "do not comma-separate the
output".
> If "decimal" is non-zero the decimal portion would never be
comma-separated.
>
>