I have 5070 rows in a Table. But in that many entries are dump entries. I simply want to ignore them. In dump entries I have 1900-01-01 00:00:00 this data in many rows, I want to ignore all the rows which is having above data.
My query looks like this
Select * from Table where AttendanceDate > #1900-01-01 00:00:00#
I tried using CDate(1900-01-01 00:00:00), "#1900-01-01 00:00:00#", <> #1900-01-01 00:00:00# as well, but nothing helps.
I have gone throuh around 15-20 SO Questions and tried their marked answers but didn't work.
EDIT
I have data like this. I want to filter data that has InTime > 1900-01-01 00:00:00.
The table has only 650 valid entries from 5070 entries. I want to remove all the other extradump entries.
Any help would be appreciated!
Thank you
As suggested in the comments you have to use the date literals in the format #MM/dd/yyyy HH:mm:ss#.
So "SELECT * FROM tbl1 WHERE Datum > #1/1/1900 00:00:00#" should work in your case. Best practise is to use parameters as mentioned in the comments but the previous SQL statement should just work fine for you.
The data type of the field in question shoud be date/time.
PS: One could use the DateValue function to convert the text in date but this will cause trouble as one can never be sure if the conversion has been successful. IMHO it's best to have the correct data type from the very beginning
"SELECT * FROM tbl1 WHERE DateValue(Datum) > #1/1/1900 00:00:00#"
I have the following query:
SELECT
D.[Year] AS [Year]
, D.[Month] AS [Month]
, CASE
WHEN f.Dept IN ('XSD') THEN 'Marketing'
ELSE f.Dept
END AS DeptS
, COUNT(DISTINCT f.OrderNo) AS CountOrders
FROM Sales.LocalOrders AS l WITH
INNER JOIN Sales.FiscalOrders AS f
ON l.ORDER_NUMBER = f.OrderNo
INNER JOIN Dimensions.Date_Dim AS D
ON CAST(D.[Date] AS DATE) = CAST(f.OrderDate AS DATE)
WHERE YEAR(f.OrderDate) = 2019
AND f.Dept IN ('XSD', 'PPM', 'XPP')
GROUP BY
D.[Year]
, D.[Month]
, f.Dept
ORDER BY
D.[Year] ASC
, D.[Month] ASC
I get the following result the ORDER BY isn't giving the right result with Month column as we can see it is not ordered:
Year Month Depts CountOrders
2019 1 XSD 200
2019 10 PPM 290
2019 10 XPP 150
2019 2 XSD 200
2019 3 XPP 300
The expected output:
Year Month Depts CountOrders
2019 1 XSD 200
2019 2 XSD 200
2019 3 XPP 300
2019 10 PPM 290
2019 10 XPP 150
Your query
It is ordered by month, as your D.[Month] is treated like a text string in the ORDER BY clause.
You could do one of two things to fix this:
Use a two-digit month number (e.g. 01... 12)
Use a data type for the ORDER BY clause that will be recognized as representing a month
A quick fix
You can correct this in your code by quickly changing the ORDER BY clause to analyze those columns as though they are numbers, which is done by converting ("casting") them to an integer data type like this:
ORDER BY
CAST(D.[Year] AS INT) ASC
,CAST(D.[Month] AS INT) ASC
This will correct your unexpected query results, but does not address the root cause, which is your underlying data (more on that below).
Your underlying data
The root cause of your issue is how your underlying data is stored and/or surfaced.
Your Month seems to be appearing as a default data type (VarChar), rather than something more specifically suited to a month or date.
If you administer or have access to or control over the database, it is a good idea to consider correcting this.
In considering this, be mindful of potential context and change management issues, including:
Is this underlying data, or just a representation of upstream data that is elsewhere? (e.g. something that is refreshed periodically using a process that you do not control, or a view that is redefined periodically)
What other queries or processes rely on how this data is currently stored or surfaced (including data types), that may break if you mess with it?
Might there be validation issues if correcting it? (such as from the way zero, null, non-numeric or non-date data is stored, even if invalid)
What change management practices should be followed in your environment?
Is the data source under high transactional load?
Is it a production dataset?
Are other reporting processes dependent on it?
None of these issues are a good excuse to leave something set up incorrectly forever, which will likely compound the issue and introduce others. However, that is only part of the story.
The appropriate approach (correct it, or leave it) will depend on your situation. In a perfect textbook world, you'd correct it. In your world, you will have to decide.
A better way?
The above solution is a bit of a quick and nasty way to force your query to work.
The fact that the solution CASTs late in the query syntax, after the results have been selected and filtered, hints that is not the most elegant way to achieve this.
Ideally you can convert data types as early as possible in the process:
If done in underlying data, not the query, this is the ultimate but may not suit the situation (see below)
If done in the query, try to do it earlier.
In your case, your GROUP BY and ORDER BY are both using columns that look to be redundant data from the original query results, that is, you are getting a DATE and a MONTH and a YEAR. Ideally you would just get a DATE and then use the MONTH or YEAR from that date. Your issue is your dates are not actually dates (see "underlying data" above), which:
In the case of DATE, is converted in your INNER JOIN line ON CAST(D.[Date] AS DATE) = CAST(f.OrderDate AS DATE) (likely to minimise issues with the join)
In the case of D.[year] and D.[month], are not converted (which is why we still need to convert them further down, in ORDER BY)
You could consider ignoring D.[month] and use the MONTH DATEPART computed from DATE, which would avoid the need to use CAST in the ORDER BY clause.
In your instance, this approach is a middle ground. The quick fix is included at the top of this answer, and the best fix is to correct the underlying data. This last section considers optimizing the quick fix, but does not correct the underlying issue. It is only mentioned for awareness and to avoid promoting the use of CAST in an ORDER BY clause as the most legitimate way of addressing your issue with good clean query syntax.
There are also potential performance tradeoffs between how many columns you select that you don't need (e.g. all of the ones in D?), whether to compute the month from the date or a seperate month column, whether to cast to date before filtering, etc. These are beyond the scope of this solution.
So:
The immediate solution: use the quick fix
The optimal solution: after it's working, consider the underlying data (in your situation)
The real problem is your object Dimensions.Date_Dim here. As you are simply ordering on the value of D.[Year] and D.[Month] without manipulating the values at all, this means the object is severely flawed; you are storing numerical data as a varchar. varchar, and numerical data types are completely different. For example 2 is less than 10 but '2' is greater than '10'; because '2' is greater than '1', so therefore it must also be greater than '10'.
The real solution, therefore, is fixing your object. Assuming that both Month and Year are incorrectly stored as a varchar, don't have any non-integer values (another and different flaw if so), and not a computed column then you could just do:
ALTER TABLE Dimensions.Date_Dim ALTER COLUMN [Year] int NOT NULL;
ALTER TABLE Dimensions.Date_Dim ALTER COLUMN [Month] int NOT NULL;
You could, however, also make the columns a PERSISTED computed column, which might well be easier, in my opinion, as DATEPART already returns a strongly typed int value.
ALTER TABLE dbo.Date_Dim DROP COLUMN [Month];
ALTER TABLE dbo.Date_Dim ADD [Month] AS DATEPART(MONTH,[Date]) PERSISTED;
Of course, for both solutions, you'll need to (first) DROP and (afterwards) reCREATE any indexes and constraints on the columns.
As long as your "Month" is always 1-12, you can use
SELECT ..., TRY_CAST(D.[Month] AS INT) AS [Month],...
ORDER BY TRY_CAST(D.[Month] AS INT)
The simplest solution is:
ORDER BY MIN(D.DATE)
or:
ORDER BY MIN(f.ORDER_DATE)
Fiddling with the year and month columns is totally unnecessary when you have a date column that is available.
A very common issue when you store numerical data as a varchar/nvarchar.
Try to cast Year and Month to INT.
ORDER BY
CAST(D.[Year] AS INT) ASC
,CAST(D.[Month] AS INT) ASC
If you try using the <, > and BETWEEN operators, you will get some really "weird" results.
I'm working on a query that pulls a date from another query, I have my reasons for the nesting. The problem I'm facing is that there is a field that is called DueDate.
My SQL is
SELECT DueDate
FROM qryDueDates
WHERE DueDates <= DateAdd("d",60,Date())
The data causing the issue is when it equals something like "1/25/2019", "11/19/2019" or any date in 2019.
Goal
I need to limit the results to show dates that are expired or expiring within 60 days or less.
I'm trying to prepare the dataset for the conditional formatting.
if you can put your nested sub-query in your post that may give better picture, and if you can mention what is the error you are getting that may also help. Since you mentioned that you are getting error only when sub-query returns certain dates, I would suggest that cast your sub-query result to DATE if you have not already done.
Below is my attempt to help you with limited information I could extract from your post. I have used some of MS-SQL function below, please replace with your DB specific function.
SELECT myDates.* FROM (select COLUMN_NAME DueDates from TABLE_NAME) as myDates WHERE myDates.DueDates <= DateAdd("d",60, GETDATE())
Turns out that the original query was screwing it up. I moved the query into the main one and it worked.
I already have a successful update query that joins tables to enter the date from the PROJECT_CLEAN table into the TABLE_PROGRESS table to show the most recent record for each evaluation unit (EU), but it keeps the date-time as a string, which I can't really do any analysis with.
I need to adjust this update query slightly to take the string version from the PROJECT_CLEAN table ("YYYY-MM-DD HH:MM:SS") and convert it to datetime (YYYY-MM-DD HH:MM:SS) in the TABLE_PROGRESS table. Here is the existing query:
UPDATE IGNORE TABLE_PROGRESS AS prog
JOIN (SELECT cast(EU AS UNSIGNED) AS eu, MAX(START_TIME) AS max, CLUSTER_COMPLETE AS complete FROM `PROJECT_CLEAN` GROUP BY EU) AS project
ON prog.EUID = project.EU
SET prog.Date_Completed = project.max
WHERE project.complete>0;
Any help will be greatly appreciated!
I figured it out. I just had to clear out the TABLE_PROGRESS table and make sure the date fields had the right format... and then the same query still worked and now the dates are no longer strings
– beck777 May 6 at 16:49
I've had a sudden failure in one of my reporting routines and have traced it back to the having portion of my statement. The function this has been serving, up until 2 days ago, was selecting the most recent date from the dbo.data_feed_file table (column name: File_Date).
Statement follows
HAVING (dbo.data_feed_file.file_date = (Select MAX(File_Date) as Expr1
FROM dbo.data_feed_file AS data_feed_file_1))
First: is there an alternative way to write this? I've gotten my report working by removing the statement, it's just 2.5 million more lines than I want. I know I can hard code the date to pull just the specific date I want, but automation is obviously preferred.
Second: Does anyone know what could cause this to spontaneously fail? I'm the only person with access to edit this query so I know nothing was changed (no really, nothing changed).
Thanks in advance.
Edit: To add clarification: There is no error message, the column headers are showing up as anticipated but no data is populated, it's just blank fields (as though nothing met the having criteria). The statement completes as though there is nothing wrong. I've confirmed there are no NULL values in the File_Date column.
I can think of two reasons why no rows would return. The first is that the subquery is returning NULL. This is easily fixed as:
HAVING (dbo.data_feed_file.file_date = (Select MAX(File_Date) as Expr1
FROM dbo.data_feed_file AS data_feed_file_1
where file_date is not null))
The second is that File_Date is stored as a datetime, rather than a date. If so, you might have a where clause that filters out the most recent value, and be missing it in the having clause. If you intend dates, but the value is stored as a datetime, then you can try:
HAVING (cast(dbo.data_feed_file.file_date as date) =
(Select cast(MAX(File_Date) as date) as Expr1
FROM dbo.data_feed_file AS data_feed_file_1
where file_date is not null))