dynamically change column name
-
Hi, Is it possible to dynamically change column name in sql select statement eg:
DECLARE @Currency NVARCHAR(50)
SET @Currency ='USD'Select Col1 as Currency+@Currency ,col2 from tbl_Emp
-
Hi, Is it possible to dynamically change column name in sql select statement eg:
DECLARE @Currency NVARCHAR(50)
SET @Currency ='USD'Select Col1 as Currency+@Currency ,col2 from tbl_Emp
As far as I am aware no, unless you create a dynamic sql statement. Further Reading for dynamic SQL by Erland Sommarskog[^]
As barmey as a sack of badgers Dude, if I knew what I was doing in life, I'd be rich, retired, dating a supermodel and laughing at the rest of you from the sidelines.
-
Hi, Is it possible to dynamically change column name in sql select statement eg:
DECLARE @Currency NVARCHAR(50)
SET @Currency ='USD'Select Col1 as Currency+@Currency ,col2 from tbl_Emp
Yup, you can change the name using an alias. Make sure that it doesn't contain spaces and stuff - Sql isn't the correct place to change the fieldname into a headername. --edit; example added
DECLARE @Currency VARCHAR(50) -- doesn't need to support unicode
SET @Currency =' USD' -- add a space for readability-- you can only concatenate strings, so cast the value to NVARCHAR
SELECT CAST(Currency AS VARCHAR) + @Currency AS [Currency]
FROM tbl_EmpI are Troll :suss:
-
Yup, you can change the name using an alias. Make sure that it doesn't contain spaces and stuff - Sql isn't the correct place to change the fieldname into a headername. --edit; example added
DECLARE @Currency VARCHAR(50) -- doesn't need to support unicode
SET @Currency =' USD' -- add a space for readability-- you can only concatenate strings, so cast the value to NVARCHAR
SELECT CAST(Currency AS VARCHAR) + @Currency AS [Currency]
FROM tbl_EmpI are Troll :suss:
Eddy Vluggen wrote:
Sql isn't the correct place to change the fieldname into a headername
Sure it is. You should have the SQL do as much as possible and avoid having to do work in code. That's one of the functions of views.
-
Eddy Vluggen wrote:
Sql isn't the correct place to change the fieldname into a headername
Sure it is. You should have the SQL do as much as possible and avoid having to do work in code. That's one of the functions of views.
-
Eddy Vluggen wrote:
Sql isn't the correct place to change the fieldname into a headername
Sure it is. You should have the SQL do as much as possible and avoid having to do work in code. That's one of the functions of views.
PIEBALDconsult wrote:
Sure it is. You should have the SQL do as much as possible and avoid having to do work in code. That's one of the functions of views.
I would say that without qualification that is not true. If I have a requirement that an Oracle proc should produce a report file then the point of that proc is in fact dedicated to correctly producing a format that represents a 'report'. So it must of course provide headers. But if I am writing a java/C# application whose point is to produce a report then the java code should provide the format. The java/C# code should provide the headers. Not the SQL. And for headers that require spaces it requires a a quoted identifier on a view. I would never do that. I would rather write a view to support the data constraints and provide additional functionality that provides the actual formatting.
-
Not my downvote, I appreciate sarcasm :) It'd be hard to globalize, since Sql server would have to know the culture of the client.
I are Troll :suss:
Eddy Vluggen wrote:
Not my downvote
I didn't think so.
Eddy Vluggen wrote:
I appreciate sarcasm
As do I, but none was intended.
Eddy Vluggen wrote:
hard to globalize
I don't see the problem, and I was making a general response to your general statement.
-
PIEBALDconsult wrote:
Sure it is. You should have the SQL do as much as possible and avoid having to do work in code. That's one of the functions of views.
I would say that without qualification that is not true. If I have a requirement that an Oracle proc should produce a report file then the point of that proc is in fact dedicated to correctly producing a format that represents a 'report'. So it must of course provide headers. But if I am writing a java/C# application whose point is to produce a report then the java code should provide the format. The java/C# code should provide the headers. Not the SQL. And for headers that require spaces it requires a a quoted identifier on a view. I would never do that. I would rather write a view to support the data constraints and provide additional functionality that provides the actual formatting.
jschell wrote:
I would say that without qualification that is not true.
I'm not sure what you're saying -- are you saying I should qualify my statement? I said "should ... as much as possible", that's the qualification.
jschell wrote:
producing a format that represents a 'report'. So it must of course provide headers.
Exactly.
jschell wrote:
if I am writing a java/C# application whose point is to produce a report
That's generally a rather poor scheme, unless the reports are very specialized and something like Crystal ( X| ) won't do. For most reports a general report engine is a far better technique. I do that to output XML of complex data. I wrote such a reporting system on my last job and there is one at my new job. Neither has the ability to alter the column headings so it must all be done in the query. The engine simply outputs the contents of a DataTable. I can add the ability to mine a couple of different ways.
-
Eddy Vluggen wrote:
Not my downvote
I didn't think so.
Eddy Vluggen wrote:
I appreciate sarcasm
As do I, but none was intended.
Eddy Vluggen wrote:
hard to globalize
I don't see the problem, and I was making a general response to your general statement.
PIEBALDconsult wrote:
I didn't think so.
I rather see a discussion than a mere anonymous judgement.
PIEBALDconsult wrote:
As do I, but none was intended.
My apologies, but your statement does require some additional musings on your motivation. The downvote indicates that someone didn't understand your point of view, whereas they might have agreed if they could read why you take that standpoint.
PIEBALDconsult wrote:
I don't see the problem
It's not "a problem"; it's an approach like many, with it's own merits. I don't like accented letters and spaces in a columnname (like Scheisse in German or Ohm in Hindi, because it messes with the report-generator and the ORM) I know that Sql Server can use long names, just like DOS moved from 8.3 to long filenames. That doesn't mean that other vendors' updated their products and also handle long names. It's not hard to fetch a list of translated names. The endusers all have powerfull PC's that are mostly used for surfing, so I like to offload some of the work to the clients. The clients' PC knows well enough in what formatting the client his dates and doubles wants. There's also a chance that your data is being reused in multiple platforms; so, Sql Server would have to know whether it can use the full columnname "Phone number" or the abbreviated one "Phone" for the Mobile-platform. I can also understand why you'd put as much logic as possible in your dataserver; give one the chance to update part of the logic by changing things in the server, without the need for recompilation of redistribution. You'll have another way of translating those headers; so either way it'll be a solved problem. ..now I'm curious to how you overcame said obstacles in Oracle.
I are Troll :suss:
-
jschell wrote:
I would say that without qualification that is not true.
I'm not sure what you're saying -- are you saying I should qualify my statement? I said "should ... as much as possible", that's the qualification.
jschell wrote:
producing a format that represents a 'report'. So it must of course provide headers.
Exactly.
jschell wrote:
if I am writing a java/C# application whose point is to produce a report
That's generally a rather poor scheme, unless the reports are very specialized and something like Crystal ( X| ) won't do. For most reports a general report engine is a far better technique. I do that to output XML of complex data. I wrote such a reporting system on my last job and there is one at my new job. Neither has the ability to alter the column headings so it must all be done in the query. The engine simply outputs the contents of a DataTable. I can add the ability to mine a couple of different ways.
My upvote, I like explanation :)
PIEBALDconsult wrote:
I wrote such a reporting system on my last job and there is one at my new job. Neither has the ability to alter the column headings so it must all be done in the query. The engine simply outputs the contents of a DataTable.
Another good reason to do put formatted data and columnnames in the table. :thumbsup:
I are Troll :suss:
-
Eddy Vluggen wrote:
Sql isn't the correct place to change the fieldname into a headername
Sure it is. You should have the SQL do as much as possible and avoid having to do work in code. That's one of the functions of views.
-
jschell wrote:
I would say that without qualification that is not true.
I'm not sure what you're saying -- are you saying I should qualify my statement? I said "should ... as much as possible", that's the qualification.
jschell wrote:
producing a format that represents a 'report'. So it must of course provide headers.
Exactly.
jschell wrote:
if I am writing a java/C# application whose point is to produce a report
That's generally a rather poor scheme, unless the reports are very specialized and something like Crystal ( X| ) won't do. For most reports a general report engine is a far better technique. I do that to output XML of complex data. I wrote such a reporting system on my last job and there is one at my new job. Neither has the ability to alter the column headings so it must all be done in the query. The engine simply outputs the contents of a DataTable. I can add the ability to mine a couple of different ways.
PIEBALDconsult wrote:
That's generally a rather poor scheme, unless the reports are very specialized and something like Crystal ( X| ) won't do.
Presumably you are comparing the difference between creating a report engine versus using an existing commercial/free one. In either case the engine itself contains the headers, while the data comes from the database.
PIEBALDconsult wrote:
I wrote such a reporting system on my last job and there is one at my new job. Neither has the ability to alter the column headings so it must all be done in the query. The engine simply outputs the contents of a DataTable. I can add the ability to mine a couple of different ways.
I have written report engines and used several others including Crystal. Whether the headers need to be modified (presumably by the user) has nothing to do with where they originate. Nor does it have anything to do with what customizable features are presented to the user. What is has to do with is separation of concerns. Your argument could lead to the supposition that one should use quoted identifiers for most tables because most tables will be used in a report and so one might as well start with the report header name.