Hostname
Role
OS
Start of Downtime
End of Downtime
Test01
Server
2019
2022-08-01 01:00:15
2022-08-07 01:00:15
Test02
Server
2019
2022-08-01 02:00:15
2022-08-03 01:00:15
Test03
Server
2019
2022-08-04 01:00:15
2022-08-05 01:00:15
Test04
Server
2019
2022-08-05 01:00:15
2022-08-06 01:00:15
Test05
Server
2019
2022-08-05 01:00:15
2022-08-06 02:00:15
I have the above table and want to report that for any moment in time at least 90% of systems don't have downtime.
In reality there are more than 5 systems.
Can anyone assist in this?
Output could be:
Date
Systems with downtime
Duration in seconds
Start of Downtime
End of Downtime
2022-08-01
2
xxxx
2022-08-01 01:00:15
2022-08-01 23:59:59
2022-08-02
2
xxxx
2022-08-02 00:00:00
2022-08-02 23:59:59
2022-08-03
2
xxxx
2022-08-03 00:00:00
2022-08-03 01:00:15
2022-08-03
1
xxx
2022-08-03 00:00:00
2022-08-03 23:59:59
2022-08-04
1
xxx
2022-08-04 00:00:00
2022-08-04 01:00:14
2022-08-04
2
xxx
2022-08-04 01:00:05
2022-08-04 23:59:59
Related
I'm migrating my Access backend to SQL Server using SSMA. The SSMA is throwing an error when making changes in the mappings. I have the Date/Time field in Access which needs to be DateTime in SQL to work. Now SSMA by default sets mappings of date to datetime2 which when run migrates successfully to SQL but is shown as a short text field in Access. When I try to manually update the mappings in SSMA from datetime2 to DateTime and start the migration I receive the following error(Please find the details of the error through the link below):
SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.
Table in Access:
[AutoNo][CNR][Datefilecreated][Datemodified][DateChangeTeamID]
2227 2620 11/04/2018 11/05/2022 11/05/2022
3078 3513 27/11/2018 11/05/2022 11/05/2022
3673 4113 24/12/2020 14/12/2021
3395 3835 25/11/2019 07/12/2021 12/10/2021
3238 3663 27/05/2019 07/12/2021
3186 3610 08/04/2019 07/04/2022
3331 3771 23/09/2019 07/12/2021
3128 3565 26/02/2019 07/12/2021 12/10/2021
2047 1993 28/04/2015 24/01/2022 28/07/2018
2767 3160 06/09/2017 07/12/2021 28/07/2018
2356 2749 25/04/2016 07/12/2021 12/10/2021
1318 1264 14/11/2011 26/01/2022 28/07/2018
2698 3091 03/07/2017 07/12/2021 12/10/2021
2551 2944 09/01/2017 07/12/2021 12/10/2021
The table in SQL when migrated from Access with datetime2
Auto number CNR Date file created Date modified DateChangeTeamID
4954 4954 2022-05-30 00:00:00.000 NULL 2018-07-28 00:00:00.000
3927 42281 2005-02-01 00:00:00.000 2017-01-11 00:00:00.000 2018-07-28 00:00:00.000
3928 42287 2002-04-01 00:00:00.000 NULL 2018-07-28 00:00:00.000
3929 42288 2005-05-05 00:00:00.000 2017-01-11 00:00:00.000 2018-07-28 00:00:00.000
3930 42289 2005-05-04 00:00:00.000 NULL 2018-07-28 00:00:00.000
3931 42290 2005-05-05 00:00:00.000 NULL 2018-07-28 00:00:00.000
3932 42291 2004-03-29 00:00:00.000 NULL 2018-07-28 00:00:00.000
3933 42292 2002-04-01 00:00:00.000 NULL 2018-07-28 00:00:00.000
SSMA Error details when migrating with destination mapping as DateTime instead of datetime2
I would consider running a query on the access (client side), and looking for some bad dates in that column.
Null dates should work just fine. It is possbile that the access column is in fact NOT a datetime column?
And yes, it is MUCH preferred to setup to use datetime in SQL server as opposed to datetime2.
However, you CAN use datetime2 in access as linked tables, and it WILL see this correctly as a datetime (and not text). But for this to work, you MUST then install + use + link your tables using the newer ODBC drivers. (native 11 or later). The 2nd fallout of this choice is that then any and all workstations that plan to use Access with these linked tables ALSO must have that SAME native 11 (or 17 or 18) installed. So, you have to re-link your tables using the newer driver, and you also have to ensure that each workstation also has that newer ODBC driver downloaded and installed on each workstation.
Above will thus allow access to see/use the datetime2 columns correctly as date time in access and VBA code.
however, as a general rule, it sounds like you have some bad dates in your original data. I would create a query that looks for say a date less then 1960, or some such, and see if any records are returned. If such older dates are not valid, then update then with a query to null values.
Sounds to me, that there exists some bad date values in that data. You could ALSO migrate, then change the datetime2 back to datetime on the server side, but with lots of tables, and lots of date columns, that could be quite a bit of work.
Since this looks to be ONLY one table, then as noted, try a query on that table in Access that looks for dates older then what your data supposed to have. Clean those out, and migrate again.
I was always under the impression given a datetime data type as 2019-07-06 was always 6th July 2019, regardless of locale and regional settings, ie this is a universal datetime format.
However, I've ran into a situation where I am trying to query some data from our database, and the string 2019-07-06 does not return the expected results. However 2019-06-07 will.
I have always had the understanding that YYYY-MM-DD format was based on ISO-8601.
Given this was on Friday 7th June where I was inserting the data, and today I am querying that data, I see:
Using the query
select
b.ID
, b.UserId
, b.EntryDate
, day(b.EntryDate) as 'day'
, month(b.EntryDate) as 'month'
from [dbo].[SomeTable] b
where b.UserId = 236328
But when I change the query:
select
b.ID
, b.UserId
, b.EntryDate
, day(b.EntryDate) as 'day'
, month(b.EntryDate) as 'month'
from [dbo].[SomeTable] b
where b.UserId = 236328
and b.EntryDate > '2019-06-07'
This does not yield any results. However changing EntryDate > '2019-07-06' will return my data.
NOTE: The query is entered using SSMS v18 on my local machine.
Server Configuration
The current verison of SQL Server is Microsoft SQL Server 2012 (SP4-GDR) (KB4057116) - 11.0.7462.6 (X64) Jan 5 2018 22:11:56 Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )
The sql server is configured to use:
|------------------|------------------------------|
| Setting | Value |
|------------------|------------------------------|
| Language | English (United States) |
| Default Language | British English |
| Server Collation | SQL_Latin1_General_CP1_CI_AS |
Database Configuration
The database is configured to use:
|---------------------|-----------------------|
| Setting | Value |
|---------------------|-----------------------|
| Collation | Latin1_General_CI_AS |
| Compatability Level | SQL Server 2012 (110) |
| Default Language | British English |
Question is, what should be the expected behaviour of date time queries with strings with format YYYY-MM-dd? I cannot recall this behaviour I am seeing in the last 20 years.
Update
For the record, if I enter the datetime in the query as 2019-06-07T00:00:00 then this DOES return the expected data.
With the DATETIME type, the literal 2019-06-07 could be 7th June, or 6th July, depending on the current DATEFORMAT settings:
SET DATEFORMAT DMY;
SELECT FORMAT(CONVERT(DATETIME, '2019-06-07'), 'dd MMM yy');
--Returns "06 Jul 19"
SET DATEFORMAT MDY;
SELECT FORMAT(CONVERT(DATETIME, '2019-06-07'), 'dd MMM yy');
-- Returns "07 Jun 19"
You should not rely on your default server settings for this, the best way to avoid this ambiguity is to use the format yyyyMMdd, this is always interpreted the same way regardless of settings:
SET DATEFORMAT DMY;
SELECT FORMAT(CONVERT(DATETIME, '20190607'), 'dd MMM yy');
--Returns "07 Jun 19"
SET DATEFORMAT MDY;
SELECT FORMAT(CONVERT(DATETIME, '20190607'), 'dd MMM yy');
-- Returns "07 Jun 19"
Alternatively, do an explicit conversion, and use the style parameter to ensure consistent conversion:
SET DATEFORMAT DMY;
SELECT FORMAT(CONVERT(DATETIME, '2019-06-07', 101), 'dd MMM yy');
-- Returns "07 Jun 19"
SET DATEFORMAT MDY;
SELECT FORMAT(CONVERT(DATETIME, '2019-06-07', 101), 'dd MMM yy');
-- Returns "07 Jun 19"
As an aside there is no ambiguity with this format when working with DATE or DATETIME2, but this ambiguity has always existed for DATETIME and SMALLDATETIME. Aaron Bertrand blogged about this in his Bad habits to kick series: mis-handling date / range queries
How to remove TIME on Epoch format in SQL Server?
Example:
2713795200000 should return Thu, 30 Dec 2055 00:00:00 instead of Thu, 30 Dec 2055 16:00:00 GMT.
You can use below query for your problem. May be its helps you.
SELECT DATEADD(DAY, (2713795200000)/(1000*60*60*24), '19700101')
I'm trying to build a dynamic pivot that essentially shows subscription amounts by customer by month. The dynamic part of the pivot is working correctly, but the resulting pivot has multiple non-identical lines per customer ID and I'm not sure why. Fair warning, I'm very new to this whole SQL thing so my code may be a complete mess and for that I'm sorry
DECLARE #DynamicPivotQuery AS NVARCHAR(MAX)
DECLARE #ColumnName AS NVARCHAR(MAX)
SELECT #ColumnName= ISNULL(#ColumnName + ',','')
+ QUOTENAME([Month])
FROM (SELECT DISTINCT TOP 99.99 PERCENT [Month] FROM [Service Contract Data].[dbo].[filtered_data] ORDER BY [Month]) AS [Month]
SET #DynamicPivotQuery =
N'SELECT [Customer ID], ' + #ColumnName + '
INTO [Service Contract Data].[dbo].[Pivot_Results] FROM [Service Contract Data].[dbo].[filtered_data]
PIVOT(SUM([Service Contract Data].[dbo].[filtered_data].[Subscription Amount])
FOR [Month] IN (' + #ColumnName + ')) AS PVTTable'
EXEC sp_executesql #DynamicPivotQuery;
#DynamicPivotQuery returns
SELECT [Customer ID], [Jan 1 2013 12:00AM],[Feb 1 2013 12:00AM],[Mar 1 2013 12:00AM],[Apr 1 2013 12:00AM],[May 1 2013 12:00AM],[Jun 1 2013 12:00AM],[Jul 1 2013 12:00AM],[Aug 1 2013 12:00AM],[Sep 1 2013 12:00AM],[Oct 1 2013 12:00AM],[Nov 1 2013 12:00AM],[Dec 1 2013 12:00AM],[Jan 1 2014 12:00AM],[Feb 1 2014 12:00AM],[Mar 1 2014 12:00AM],[Apr 1 2014 12:00AM],[May 1 2014 12:00AM],[Jun 1 2014 12:00AM],[Jul 1 2014 12:00AM],[Aug 1 2014 12:00AM],[Sep 1 2014 12:00AM],[Oct 1 2014 12:00AM],[Nov 1 2014 12:00AM],[Dec 1 2014 12:00AM],[Jan 1 2015 12:00AM],[Feb 1 2015 12:00AM],[Mar 1 2015 12:00AM],[Apr 1 2015 12:00AM],[May 1 2015 12:00AM],[Jun 1 2015 12:00AM],[Jul 1 2015 12:00AM],[Aug 1 2015 12:00AM],[Sep 1 2015 12:00AM],[Oct 1 2015 12:00AM],[Nov 1 2015 12:00AM],[Dec 1 2015 12:00AM],[Jan 1 2016 12:00AM],[Feb 1 2016 12:00AM]
INTO [Service Contract Data].[dbo].[Pivot_Results] FROM [Service Contract Data].[dbo].[filtered_data]
PIVOT(SUM([Service Contract Data].[dbo].[filtered_data].[Subscription Amount])
FOR [Month] IN ([Jan 1 2013 12:00AM],[Feb 1 2013 12:00AM],[Mar 1 2013 12:00AM],[Apr 1 2013 12:00AM],[May 1 2013 12:00AM],[Jun 1 2013 12:00AM],[Jul 1 2013 12:00AM],[Aug 1 2013 12:00AM],[Sep 1 2013 12:00AM],[Oct 1 2013 12:00AM],[Nov 1 2013 12:00AM],[Dec 1 2013 12:00AM],[Jan 1 2014 12:00AM],[Feb 1 2014 12:00AM],[Mar 1 2014 12:00AM],[Apr 1 2014 12:00AM],[May 1 2014 12:00AM],[Jun 1 2014 12:00AM],[Jul 1 2014 12:00AM],[Aug 1 2014 12:00AM],[Sep 1 2014 12:00AM],[Oct 1 2014 12:00AM],[Nov 1 2014 12:00AM],[Dec 1 2014 12:00AM],[Jan 1 2015 12:00AM],[Feb 1 2015 12:00AM],[Mar 1 2015 12:00AM],[Apr 1 2015 12:00AM],[May 1 2015 12:00AM],[Jun 1 2015 12:00AM],[Jul 1 2015 12:00AM],[Aug 1 2015 12:00AM],[Sep 1 2015 12:00AM],[Oct 1 2015 12:00AM],[Nov 1 2015 12:00AM],[Dec 1 2015 12:00AM],[Jan 1 2016 12:00AM],[Feb 1 2016 12:00AM])) AS PVTTable
I have these dates, that I need converted to date:
Sat Nov 22 2014 01:01 AM CET
Mon Aug 18 2014 06:32 PM CEST
All the convert or cast functions I tried didn't work, maybe someone has an idea what to do?
In the end, I would need something like
YYYY-MM-DD HH:MM:SS or DD.MM.YYYY HH:MM:SS that doesn't really matter, but I would need them in the same timezone if at all possible...
Thank You for any ideas
SQL Server can convert that if you get rid of the day of the week at the beginning and the time zone at the end:
SELECT CONVERT(DATETIME, SUBSTRING('Sat Nov 22 2014 01:01 AM CET',4,LEN('Sat Nov 22 2014 01:01 AM CET')-7))
SELECT CONVERT(DATETIME, SUBSTRING('Mon Aug 18 2014 06:32 PM CEST',4,LEN('Mon Aug 18 2014 06:32 PM CEST')-7))
I'm not sure what you mean that you need them in the same time zone.