| Groups | Blog | Home |
sql server (alternate) : How can I conserve the initial zero when convert numeric to string using STR()
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.
You can't "preserve" the zero. Integer 06 = Integer 6 = Integer
00000000006. If you want to convert an integer to a varchar you can prepend a 0 character to the result: SELECT '0' + CAST(06 AS VARCHAR) Returns '06'. The downside to this method is that if you do something like SELECT '0' + CAST(10 AS VARCHAR) You'll end up with '010' which may or may not be what you want. You can build on this example with the SUBSTRING function to get exactly what you really want out of it. [quoted text, click to view] <angellian@gmail.com> wrote in message news:1148779910.070643.296910@g10g2000cwb.googlegroups.com... > 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. >
You are confusing the PHYSICAL display with the internal LOGICAL model.
This is SQL and not COBOL. There is no initial zero in a number; there is an internal binary, BCD or whatever the hard uses representation. Your next problem is that you do not understand that dispaly is NEVER done in the database, but in the front end application. That is the most basic concept of *any* tiered architecture, not just SQL.
--CELKO-- (jcelko212@earthlink.net) writes:
[quoted text, click to view] > Your next problem is that you do not understand that dispaly is NEVER > done in the database, but in the front end application. That is the > most basic concept of *any* tiered architecture, not just SQL. Working so long as you have done in the database trade should have learnt you to never say never. 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. Which typically is the case for admin stuff. -- Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at
[quoted text, click to view]
> This is SQL and not COBOL. There is no initial zero in a number; there > is an internal binary, BCD or whatever the hard uses representation. This is SQL SERVER not SQL and not COBOL, SQL SERVER has many facilities to aid the developer in creating a highly scalable, robust and maintainable architecture. Standard SQL is very weak in terms of features that we need out in the real world. [quoted text, click to view] > Your next problem is that you do not understand that dispaly is NEVER > done in the database, but in the front end application. That is the > most basic concept of *any* tiered architecture, not just SQL. "Display" can never be done in the database because the database is a service and has such has no UI, we use tools to get at the data. The big problem here is your continued misconception that ALL formatting should be done in the front end application, have you actually sat down and thought about what that means? The fundemental principle of tiered architecture design and development is that formatting is done where it is most sensible and efficient, in terms of development and support cost and in terms of performance. My blog entry on this covers in more detail: http://sqlblogcasts.com/blogs/tonyrogerson/archive/2006/05/11/429.aspx 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? Anyway, you are still stuck in the mainframe model of all resources are in the same box and that you use the VTAM protocol out to remote terminals. -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials [quoted text, click to view] "--CELKO--" <jcelko212@earthlink.net> wrote in message news:1148830663.994422.182500@y43g2000cwc.googlegroups.com... > You are confusing the PHYSICAL display with the internal LOGICAL model. > > > This is SQL and not COBOL. There is no initial zero in a number; there > is an internal binary, BCD or whatever the hard uses representation. > > Your next problem is that you do not understand that dispaly is NEVER > done in the database, but in the front end application. That is the > most basic concept of *any* tiered architecture, not just SQL. >
Hi Angellian,
For 2 character string you can just use CASE... declare @number tinyint set @number = 2 select case when @number between 0 and 9 then '0' else '' end + cast( @number as varchar(2) ) Otherwise, if your resultant string needs to be bigger than 2 characters do this... declare @number int declare @string varchar(10) declare @size_of_fixed_string tinyint set @size_of_fixed_string = 10 set @number = 40 print replicate( '0', @size_of_fixed_string ) set @string = left( replicate( '0', @size_of_fixed_string ), @size_of_fixed_string - len( @number ) ) + cast( @number as varchar(10) ) print @string http://sqlblogcasts.com/blogs/tonyrogerson/archive/2006/05/29/765.aspx -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials [quoted text, click to view] <angellian@gmail.com> wrote in message news:1148779910.070643.296910@g10g2000cwb.googlegroups.com... > 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. >
Something like this may help...Assuming your column name is COLUMN1 and
COLUMN1 has a numeric type. select case when COLUMN1 < 10 then '0' + cast(COLUMN1 as varchar(10)) end when COLUMN1 > = 10 then cast(COLUMN1 as varchar(10)) end .......(rest of your statement...) Hope this helps...
[quoted text, click to view]
>> 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, which is a program and not part of SQL. Trust me, we never voted on a "standard query tool" in ANSI X3H2.
[quoted text, click to view]
>> 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.
Just cause I've seen a couple of examples using CASE; I use trick
similar to your second example: SELECT RIGHT('0' +CONVERT(varchar(2), @number), 2) Granted, it only works on a two-digit number, but it saves typing. The REPLICATE idea is pretty smooth, though. Stu [quoted text, click to view] Tony Rogerson wrote:
> Hi Angellian, > > For 2 character string you can just use CASE... > > declare @number tinyint > set @number = 2 > > select case when @number between 0 and 9 then '0' else '' end + cast( > @number as varchar(2) ) > > Otherwise, if your resultant string needs to be bigger than 2 characters do > this... > > declare @number int > declare @string varchar(10) > declare @size_of_fixed_string tinyint > set @size_of_fixed_string = 10 > set @number = 40 > > print replicate( '0', @size_of_fixed_string ) > > set @string = left( replicate( '0', @size_of_fixed_string ), > @size_of_fixed_string - len( @number ) ) + cast( @number as varchar(10) ) > > print @string > > http://sqlblogcasts.com/blogs/tonyrogerson/archive/2006/05/29/765.aspx > > -- > Tony Rogerson > SQL Server MVP > http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL > Server Consultant > http://sqlserverfaq.com - free video tutorials > > > <angellian@gmail.com> wrote in message > news:1148779910.070643.296910@g10g2000cwb.googlegroups.com... > > 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. > >
[quoted text, click to view]
--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
[quoted text, click to view]
> 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. [quoted text, click to view] > 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 [quoted text, click to view] "--CELKO--" <jcelko212@earthlink.net> wrote in message news:1149114884.873451.172270@g10g2000cwb.googlegroups.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. >
[quoted text, click to view]
>> 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 "application 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
--CELKO-- (jcelko212@earthlink.net) writes:
[quoted text, click to view] >>> 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. << [quoted text, click to view] > > 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. [quoted text, click to view] > 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, esquel@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at
Anith Sen (anith@bizdatasolutions.com) writes:
[quoted text, click to view] > 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, esquel@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at
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 [quoted text, click to view] "Anith Sen" <anith@bizdatasolutions.com> wrote in message news:e5n83p$v6r$1@nntp.aioe.org... >>> 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 "application 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 >
Don't see what you're looking for? Try a search.
|
January 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
| home · blog · groups | Questions? Comments? Contact the dn |