How can I conserve the initial zero when convert numeric to string using STR()

[angellian]

Sorry to raise a stupid question but I tried many methods which did
work.
how can I conserve the initial zero when I try to convert STR(06) into
string in SQL statment?
It always gives me 6 instead of 06.

Thanks a lot.

[Damien]

--CELKO-- wrote:

I see you use CTE, why don't you pull the results down into the application, CTE's are a form of formatting for display purposes, as is COALESCE on the SELECT clause, as is ORDER BY etc... Just where do you draw the line? <<

UNH? CTEs are virtual tables and have nothing to do with display. Do
ypou also think that VIEWs and derived tables are formatting for user
display? COALESCE is a function that works with NULLs and CAST() to
get another internal data type result.

Things like CONVERT() on dates or PRINT in T-SQL is formatting.

Hi Joe,

I didn't understand Tony's point about CTEs, but I think his point
about COALESCE stands. Surely, COALESCE is shorthand for having
formatting code at the front end like:

If Column1 is not null then
show Column1
Else if column2 is not null then
show Column2
Else if column3 is not null then
:
:
:
Else
show ColumnN
End If

Damien

[Tony Rogerson]

> UNH? CTEs are virtual tables and have nothing to do with display. Do

ypou also think that VIEWs and derived tables are formatting for user
display? COALESCE is a function that works with NULLs and CAST() to
get another internal data type result.

Things like CONVERT() on dates or PRINT in T-SQL is formatting.
Ok - I conceede CTEs, I was thinking about them within the scope of paging
on which you have in the past stated you would have the front end perform,
that literally means pushing a million rows over the network to the front
end.
Things like CONVERT() on dates or PRINT in T-SQL is formatting.

The operator was trying to create a string with leading zeros which you
stated should be done in the front end.

Why on earth would you want to go to all the effort of using a 3GL / 4GL to
format the data when you can just simply do it in TSQL within the SQL Server
itself - nice and simple, nice and easy to support and maintain.

Your method relies on additional skills, the developer would need to
understand a programming language as well as SQL, that then translates into
a support and maintanence burden which costs money.

You can very easily do the formatting in the TSQL and use Integration
Services or DTS to export the data out to whatever you want - XML, XLS
etc...

Your recommendations around formatting date back to the 70's where rdbms
didn't have many facilities available for the developer other than SUM,
COUNT, MIN, MAX and AVG.

--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials
"--CELKO--" <jc*******@eart hlink.net> wrote in message
news:11******** **************@ g10g2000cwb.goo glegroups.com.. .

I see you use CTE, why don't you pull the results down into the
application, CTE's are a form of formatting for display purposes, as is
COALESCE on the SELECT clause, as is ORDER BY etc... Just where do you
draw the line? <<

UNH? CTEs are virtual tables and have nothing to do with display. Do
ypou also think that VIEWs and derived tables are formatting for user
display? COALESCE is a function that works with NULLs and CAST() to
get another internal data type result.

Things like CONVERT() on dates or PRINT in T-SQL is formatting.

[Anith Sen]

>> Why on earth would you want to go to all the effort of using a 3GL / 4GL

to format the data when you can just simply do it in TSQL within the SQL
Server itself - nice and simple, nice and easy to support and maintain.

The general answer is that one would prefer to have the centralized database
as generic as possible so that it can support a variety of applications.

Having an application specific formatting at the central data source tend to
generate something called "applicatio n bias". Considering the OP's question,
given certain 5 applications requesting same data formatted in 5 different
ways, should he formulate a single generic query and do the formatting in
the application or should he create 5 different queries to support each
application? How about when the number of applications increases to 50? Or
say 500?

While it may appear to be efficient and easy to manage in the short term, it
can often be highly detrimental to the long term stability and management of
data centric systems.

This is nothing new but such bias is known to software engineers for decades
now. For details on why this separation of concern is important for data
oriented systems, ~Principles of Program Design~ by Michael Jackson is a
good book.

--
Anith

[Erland Sommarskog]

--CELKO-- (jc*******@eart hlink.net) writes:

There is at least one obvious case where formatting of output must be

done in SQL: to wit when the display is done in a standard query tool like
Query Analyzer. <<
No, that formatting is done in the Query Analyzer,
QA only has a standard formatting, with no options to specify a how a
certainly column should look like.

Thus, if you want a certain format when you look at the data in QA, SQL
is the only place to do formatting.
which is a program and not part of SQL. Trust me, we never voted on a
"standard query tool" in ANSI X3H2.

I never said so. I only meant to say that it is a plain query tool,
and about every RDBMS comes with one.
--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

[Erland Sommarskog]

Anith Sen (an***@bizdatas olutions.com) writes:

The general answer is that one would prefer to have the centralized
database as generic as possible so that it can support a variety of
applications.

I think the Perl has the right answer to this: There is more than one
way do it!

That is, if you can do things either in the server or the in the client/
middile layer, you can pick what fits best for the situation.
--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

[Tony Rogerson]

I think of it the other way round, surely the 5 applications would call 1
single query and not different queries for different applications.

SQL Server is more a service orientated architecture, well - becoming that
anyway.

So, doing things centrally in the SQL Server is better because you only need
do it once and not in 5 places in 5 different langauges requiring 6
different skill sets.

--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials
"Anith Sen" <an***@bizdatas olutions.com> wrote in message
news:e5******** **@nntp.aioe.or g...

Why on earth would you want to go to all the effort of using a 3GL / 4GL
to format the data when you can just simply do it in TSQL within the SQL
Server itself - nice and simple, nice and easy to support and maintain.

The general answer is that one would prefer to have the centralized
database as generic as possible so that it can support a variety of
applications.

Having an application specific formatting at the central data source tend
to generate something called "applicatio n bias". Considering the OP's
question, given certain 5 applications requesting same data formatted in 5
different ways, should he formulate a single generic query and do the
formatting in the application or should he create 5 different queries to
support each application? How about when the number of applications
increases to 50? Or say 500?

While it may appear to be efficient and easy to manage in the short term,
it can often be highly detrimental to the long term stability and
management of data centric systems.

This is nothing new but such bias is known to software engineers for
decades now. For details on why this separation of concern is important
for data oriented systems, ~Principles of Program Design~ by Michael
Jackson is a good book.

--
Anith