|
Thanks, I will try but as sort is set by default as ASC in SQL server, I never put asc separately.
|
|
|
|
|
AnirbanM 2 wrote: Out of 100 times running this query, 97-98 times, it's producing correct result, however, 1-2 times, sort is not working, so instead of 1st to 31st, output coming like 10th to 31st then 1st to 10th.
From that, I'd say you have different collations (or regional settings on the client). But AFAIK, that would only apply to string-types, like VARCHAR and NTEXT .
Try converting the datetime to a fixed-format string, and sort on that.
|
|
|
|
|
Thanks for your reply. In SQL server, regional setting is set as default. Moreover, I need to do sorting based on Date only otherwise, it will defeat my purpose. However, as you are saying, i will try to do so.
|
|
|
|
|
I got a gut-feeling saying it's converting to DATE to a VARCHAR , that's the only way to have 10 precede the number 2.
Contrary to the previous advice, what happens when you cast it to a DOUBLE ? Internally, a date is a floating-point number.
|
|
|
|
|
I notice that your table has Month, Year, Days all as character. If the sort uses these columns it might produce your problem.
|
|
|
|
|
Thanks for varchar columns are not included in sorting.
|
|
|
|
|
Always always always store date/time related values as DATE, DATETIME, etc.; never as string.
|
|
|
|
|
His ToDate is stored as a Date type, first thing I looked for!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
And yet his OrderBy is Todate
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Which is an all-you-can-eat sushi place -- very fishy indeed...
|
|
|
|
|
Thanks for your reply, however, i'm not getting your point, if i'm sorting based on date and other fields are characters, what's the problem? If anything there, i will surely change it.
|
|
|
|
|
Thanks, but sort is based on Date column only. As you rightly said, I always keep date as date column only. Month, Year, NoofDays etc, these columns are meant to be varchar, these are not included for sorting.
|
|
|
|
|
There are a bunch of uglies in this table design
1. Storing numerics as character
2. Mixing varchar and nchar for no obvious reason
3. Using nchar instead of char (I would use varchar)
4. Using nchar instead of a bit (holiday)
Personally I think you should have only 3 fields in the table SNo,ToDate and Holiday. All the others should be calculated in a view!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
Thanks for your valuable feedback. I will change all nchar to varchar and holiday to bit. Moreover, I can safely remove Month and Date. But as you are suggesting, rest of the fields are calculative, then I need to make query then construct data table, make calculation and then put it into grid, otherwise, i'm simply getting all values from sql and putting straightaway into grid. So I made a trade off here, though it may not be the best way to do so.
|
|
|
|
|
What I can't understand and one of the puzzle is why SQL Server is not consistent and giving different results based on same query? Why out of 100 times, 97-98 times giving correct results and 1-2 times giving wrong.
|
|
|
|
|
Please note I did not offer ANY help on that subject - it does not make any sense to me so I concentrated on the other areas hoping they may have an impact on your results.
To me a query cannot return inconsistent results!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Yes, that's my core question. even if my table design is not good, even if SQL may internally converting date into float or even if i need to put 'ASC' after Order By, still question remains same. Why on earth SQL query is not consistent? Why not it's producing same results 100 out of 100 times? Is that means any internal bug in the SQL Server? Thanks.
|
|
|
|
|
Actually, based on the query results, within a loop creating new records and putting into a new SQL table 'Timesheet'. Now, when I see this new table 'Timesheet', it's rows are not created based on that sorting. For example, output of the query I got as 1/1/2012 to 1/31/2012 and now in the new table, inserting records like :
1/1/2012 - 51 - 12
1/2/2012 - 10 - 13
1/3/2012 - 15 - 20
..... till
1/31/2012 - 40 - 30
Now, sometimes (as I said earlier), it's creating rows in 'Timesheet' table that looks like:
1/12/2012 - 10 -20
1/13/2012 - 15-12
.. then
1/31/2012 - 40 - 30
..then
1/1/2012 - 51 - 12
1/2/2012 - 10 - 13
1/3/2012 - 15 - 20
It's not that all errors are starting from 1/12/2012, it can be 10th or 15th. So no possible pattern in these output which are giving error.
May be it will give more light into this matter. thanks.
|
|
|
|
|
..and the table "timesheet" holds the day as a VARCHAR ? That's not a bug, that's by design. Strings are sorted depending on the settings, should have been DATE type.
|
|
|
|
|
No sir, the sorting is made on 'ToDate' column which is of Date type, not varchar type, as I already given my column types before.
|
|
|
|
|
AnirbanM 2 wrote: No sir, the sorting is made on 'ToDate' column which is of Date type, not varchar type, as I already given my column types before.
Still, it sorts like it would be. Can you create a TSQL-script that reproduces the problem? Seems I can't, my dates keep returning ordered in a way that could be expected;
DECLARE @TEST TABLE (SD DATE);
INSERT INTO @TEST (SD) VALUES ('20010101');
INSERT INTO @TEST (SD) VALUES ('20011010');
INSERT INTO @TEST (SD) VALUES ('20010310');
INSERT INTO @TEST (SD) VALUES ('20010210');
INSERT INTO @TEST (SD) VALUES ('20010301');
INSERT INTO @TEST (SD) VALUES ('20010201');
SELECT * FROM @TEST ORDER BY SD;
Results:
2001-01-01
2001-02-01
2001-02-10
2001-03-01
2001-03-10
2001-10-10
|
|
|
|
|
I would think the error is happening after the query is returned. Test the query in SQL alone and see if you get the error you describe.
|
|
|
|
|
AnirbanM 2 wrote: Please suggest where is the problem, thanks to all in advance.
Some posssible reasons.
- The problem originates from some other place in the code. So nothing to do with the code that you posted. And one very obvious possibility is that there is code somewhere that is sorting based on alphabetic ("10", "11" versus "1", "2) instead of using the sort that you gave.
- You are not looking at the actual data.
- You are not running the code that you think you are.
|
|
|
|