This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I have a column named TNAME of type nvarchar2(8) in my table. Length is 8 as you see. There are a few records in the table and all of them has 8 symbols in that column. When I select that column the value contains only 7 symbols. If I select length(TNAME) from mytable, result is 8!!!
see the pic.
Why is this happening, any idea?
ANOTHER PIC
Let's be quite clear about this: Oracle is not the most expensive database in the world because it habitually asserts ('CMN00632' = 'CMN0063') is true. So the problem lies somewhere in your set-up, either in your environment config or in your data itself.
You remain adamant that there is no problem with your GUI. There is no way for us to validate this. However, if you're wrong, you're the only person who's affected so we'll just assume you're right.
The other possibility then is that your data is corrupted in some fashion, perhaps non-printing characters. Is this problem affecting ebvery row or just certain values in the table?
Either way, there's a simple check you can run:
select dump(tname)
from merchants
where tname = 'CMN00632';
The output shoudl be the ASCII values for that string: 67,77,78,48,48,48,51,50.
Incidentally it would be quite straightforward to prove that there is no truncating format associated with that column: use a column alias . What does this query return?
select tname as some_new_name
from merchants
where tname = 'CMN00632';
the query is correct. As you can see the record matches with your condition CMN00632. The reason why you are getting the result upto only 3 is because the GUI cuts off the value. Try to resize your column TNAME and you will see the whole value.
This is happening because in setting, somewhere you have set to display the column data max to 7 characters.
If you execute your query in command prompt, you will see proper result.
Execute below query in your editor and see what it gives.
select '123456789' as test from merchants;
I bet this will give result as 1234567 in your editor that you are using.
Also one basic question, Do you think you will get the row displayed in your image with the query you have?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
So this isn't a technical question, but rather questioning why a language is designed the way it is.
I've been learning SQL and one thing that's been bothering me greatly is how SQL asks you to name the column you want and THEN name the table you want to get it from. To me, it would make more sense that you refer to the parent body (which is the table) and THEN the column it has. But SQL seems to forces users to do it the other way around. Why?
I'm just curious as to why the language is designed this way.
SELECT column
FROM table
why not
FROM table
SELECT column
SQL tries to mimic English language to some extent, so that it feels natural to formulate the query.
In spoken English you would say something like "I want the names of the employees". You would not say "I want of the employees their names" or something like that.
But you are right, it might have been a good idea to have the query represent the order of execution. And "From the employee table I want the names" would not be so far off the mark :-)
SQL is a descriptive language, not a procedural language. It describes the result set being produced. And, you can think of that result set as a report, with column headers.
As such, the basic querying construct returns those column headers. The rest of the query describes how they are produced.
You may find this post useful. Starting with FROM is the most logical way to think about a query (Why would anyone write SELECT before knowing what to SELECT from?). However, SQL guidelines were designed as if your query were a command. Thus, you are commanding the system to SELECT the data for you, and the FROM further specifies that command.
Of course, the actual execution is distinct from the lexical and logical orders above.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Given a table with this structure:
create table person (
id int identity primary key,
name varchar(256),
birthday datetime
)
For this query:
select id,name,birthday,haircolor from person
What is the rational behind SQL throwing an error in this situation? I was considering how flexible it would be if queries would simply return null for non existent columns. What would be concrete reasons for or against such a SQL language design?
No, because then you'd assume there is a haircolour column which could then have the following implications, just as an example:
You'd think you could insert into the field since you would assume that the column exists,
The returned result would not be an accurate representation of the database schema.
Errors are given so that you can have a clear understanding and indication of what you can and
cannot do. It's also there so you can catch exceptions, bugs, spiders, and of course creepy crawlies as soon as possible. :)
We dont wan't to accomdate lazy developers.
Do the right thing, be a man - Russel Peters.
This would be inconsistent for many reasons. One simple example is use of * to select the column: when you do this
select id, name, birthday, hair_color from person
and get back a table with all four columns present (hair_color is set to null on all rows) you would reasonably expect that the query below
select * from person
returned at least four columns, and that hair_color is among the columns returned. However, this wouldn't be the case if SQL allowed non-existent columns to return nulls.
This would also create hard-to-find errors when a column gets renamed in the schema, but some of the queries or stored procedures do not get re-worked to match the new names.
Generally, though, SQL engine developers make tradeoffs between usability and "hard" error checking. Sometimes, they would relax a constraint or two, to accommodate some of the most common "simple" mistakes (such as forgetting to use an aggregate function in a grouped query; it is an error, but MySql lets you get away with it). When it comes to schema checks, though, SQL engines do not allow any complacency, treating all missing schema elements as errors.
MySQL has one horrible bug in it...
select field1,field2,filed3
from table
group by field1
Any database engine would return 'error, wtf do I do with the field2 and field3 in the select line when they are not an aggregate nor in the group by statement'.
MySQL on the other hand will return two random values for field 2 and 3, and not return an error (which I refer to as 'doing the wrong thing and not returning an error'). THis is a horrid bug, the number of scripts of troubleshooted to discover theat MySQL is not handling group by's correctly is absurd...give an error before giving unintentional results and this huge bug won't be such an issue
Doesn't it seem to you that you are requesting more of this stupid behaviour to be propagated...just in the select clause instead of the group by clause?
edit:
typo propagation as well.
select age,gender, haricolour from...
I'd prefer to get an error back saying 'great typo silly' instead of a misnamed field full of nulls.
This would result in a silent errors problem. The whole reason you have compile time errors and runtime exceptions is to catch bugs as soon as possible.
If you had a typo in a column name and it returned null instead of an error, your application will continue to work, but various things would misbehave as a result. You might have a column that saves a user setting indicating they don't want to receive emails. However your query has a typo and so it always returns null. Gradually a few people begin to report that they are setting the "Do not send emails" setting but are still getting emails. You have to hunt through all your code to figure out the cause. First you look at the form that edits this setting, then at the code that calls the database to save the setting, then you verify the data exists and the setting is getting persisted, then you look at the system that sends emails, and work your way up to the DB layer there that retrieves settings and painstakingly look through the SQL for that typo.
How much easier would that process be if it had just thrown an error in the first place? No users frustrated. No wasting time with support requests. No wasting time troubleshooting.
Returning null would be too generic. I like it this way much better. In your flow you can probably catch errors and return null if you want. But giving more info about why the query failed is better than receiving a null (and probably have you scratch your head on your JOIN and WHERE clauses
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
Sorry for the whole BIG query pasted below. I have gone though it over and over and over and checked places where there might be calculation errors like dividing by zero, but none works. Right now it asks me to use group by clause, like the error we get when we have a count in the select statement, and don't use a group by clause. But When I put a group by clause at the end of the query with all the columns listed out, it tells me that the column names don't exists!
You are using sum on line 45 of your SQL:
(case ((sum(T.act_work_qty)+sum(T.remain_work_qty))*100.0)
when 0 then 0
when null then 0
else round((sum(T.act_work_qty)/(sum(T.act_work_qty)+sum(T.remain_work_qty))*100.0),2)
end)
Because of this, SQL assumes you have an aggregation query and returns an aggregation error.
Here are some ideas for workarounds . . .
Perhaps you don't need the sum, so you can just use the column value.
You can use a windows function to calculate the sum . . . sum(T.act_work_qt) over () will calculate the sum over all the rows processed by the query (the where clause conditions are applied).
Use a subquery to calculate the sum.
I have a table containing a series of survey responses, structured like this:
Question Category | Question Number | Respondent ID | Answer
This seemed the most logical storage for the data. The combination of Question Category, Question Number, and Respondent ID is unique.
Problem is, I've been asked for a report with the Respondent ID as the columns, with Answer as the rows. Since Answer is free-text, the numeric-expecting PIVOT command doesn't help. It would be great if each row was a specific Question Category / Question Number pairing so that all of the information is displayed in a single table.
Is this possible? I'm guessing a certain amount of dynamic SQL will be required, especially with the expected 50-odd surveys to display.
I think this task should be done by your client code - trying to do this transposing on SQL side is not very good idea. Such SQL (even if it can be constructed) will likely be extremely complicated and fragile.
First of all, you should count how many distinct answers are there - you probably don't want to create report 1000 columns wide if all answers are different. Also, you probably want to make sure that answers are narrow - what if someone gave really bad 1KB wide answer?
Then, you should construct your report (would that be HTML or something else) dynamically based on results of your standard, non-transposed SQL.
For example, in HTML you can create as many columns as you want using <th>column</th> for table header and <td>value</td> for data cell - as long as you know already how many columns are going to be in your output result.
To me, it seems that the problem is the number of columns. You don't know how many respondents there are.
One idea would be to concatenate the respondent ids. You can do this in SQL Server as:
select distinct Answer,
(select cast(RespondentId as varchar(255))+'; '
from Responses r2
where r2.Answer = r.Answer
for xml path ('')
) AllResponders
from Responses r
(This is untested so may have syntax errors.)
If reporting services or excel power pivot are possibilities for the report then they could both probably accomplish what you want easier than a straight sql query. In RS you can use a tablix, and in power pivot a pivot table. Both avoid having to define your pivot columns in an sql pivot statement, and both can dynamically determine the column names from a tabular result set.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
So I inserted some data on my table, ran a Select Count(*) query, and showed the result, it was 120, then I deleted the data of the table from sqldeveloper, ran my VB project again with the same query as before just to test if it worked ok, and to my surprise it returned the same value as before! Still 120, although the same exact Select Count query does return 0 from sqldeveloper, I already closed the project and opened it again, no change. What could be happening?
This is my query code:
sql.CommandText = "select count(*) from mytable"
sql.CommandType = CommandType.Text
sql.Connection = conexion.con
test = Convert.ToInt32(sql.ExecuteScalar().ToString())
TextBox1.Text = test.ToString()
test is an Integer variable, the reason I convert it to an Integer is because I want to evaluate the result and decide what to do based on the number returned by the query.
VB.NET 3.5 and Oracle10g XE
I'll answer this myself just in case anyone else encounters this issue in the future, indeed as the commenters have said, you have to COMMIT everything you do on SQLdeveloper before expecting to see any actual changes in the database, just as if it was an actual SQL Transaction.
Thanks to the people that commented on this.