I have some experience with Tableau as I have migrated into a Data Analyst position with not a ton of experience and am hitting a wall with if it is even possible to perform the calculation within Tableau.
The general base of my data would look like (Limiting it to the two fields we need)
Case # | Tech Dispatch Time (PST) | Full Time (Y/N)
2017-0001| MM/DD/YYYY 16:34:21 | 0
2017-0002| MM/DD/YYYY 20:43:00 | 1
2017-0003| MM/DD/YYYY 22:00:05 | 0
We are looking to see how often a dispatch happens within X amount of time to determine our efficiency in dispatching our teams. If these were happening on the same record, a basic DATEDIFF and IF function would work, but I am at a loss on how to state that IF there is another dispatch in say 180 minutes, 1, else 0.
Is this something I will have to do outside of Tableau within say SQL or PowerPivot? Or is this a function that Tableau could calculate as well?
Thank you for your time and assistance with this matter,
Andy M.
Create a parameter to define your 'x',
Then create a calculated field with below Formula(I called it time block)
//We need to add 0.5 to Roundup
ROUND((DATEDIFF('minute',[Tech Dispatch Time],NOW())/[x])+0.5,0)
Now you can use it in your viz
Use the LOOKUP() function. It allows you to find other rows' values relative to the current row.
DateDiff("minute", [Tech Dispatch Time (PST)], Lookup(MIN([Tech Dispatch Time (PST)]), -1))
The sample data you have in your question presents a problem though. The Tech Dispatch Time (PST) field only has the time portion. To accurately calculate time difference, you need a date with the time. Otherwise, you will end up with negative times if the two cases span across midnight.
Since this is a table calc, you'll also have to set the partitioning and addressing dimensions and sort order by editing the table calc to get the effect you want.
Related
Good day all,
I am trying to filter todays result in SQL table to a collection in powerapps. The column "dt" represents the column in sql of datetime type.
This is my powerapps filter:
ClearCollect(myCollectionName, Filter(myDatasource, Text(dt,"dd/mm/yyyy") = Text(Now(),"dd/mm/yyyy" )));
Seems like the collection is still empty even there is data for today in sql. May I know if my approach is the correct way in filtering?
Short answer: the data is likely being changed based on the client time zone. To fix it, you can update it by applying the time zone offset to the data from the SQL table, something along the lines of:
ClearCollect(
myCollectionName,
Filter(
myDatasource,
Text(DateAdd(dt, TimeZoneOffset(dt), Minutes), "dd/mm/yyyy") =
Text(Now(), "dd/mm/yyyy")))
Long(er) answer: the datetime type in SQL Server represents an absolute value of date and time. For example, the value '2021-12-23 09:30:00' represents 9:30 in the morning of the 23rd day of December, 2021 - at any part of the world. The date/time type in Power Apps, however, represents a point in time, typically referring to the local time where the app is being executed (or created). For example, if I selected that value and I'm in the US Pacific Time Zone (UTC-08:00), that would represent the same value as if someone in London (UTC+00:00) selected 2021-12-23 17:30:00. Since the two types represent different concepts, we may have mismatches like you are facing. To fix this, we can either use a type in SQL Server that has the same semantics as Power Apps (for example, 'datetimeoffset'), or adjust the time when it is being transferred between SQL and Power Apps.
The blog post at https://powerapps.microsoft.com/en-us/blog/working-with-datetime-values-in-sql explains in more details how to work with date/time values in SQL and Power Apps.
I'm new of MDX and I'm trying to calculate a new measure based on two different date dimensions.
I have the Creation Date Dimension (with Year, Trimester, Month, Day) and Resolution Date (with Year, Trimester, Month, Day).As measure I have the number of tickets and I want to calculate two new measures in order to know how many tickets that were resolved this month were actually created last month and how many tickets were resolved in the same month as they were created.
I found this interesting post, but I cannot understand how to use properties..
https://bennyaustin.com/2012/06/05/ssas-mdx-calculated-measures-that-require-date-comparison/
Any ideas or suggests?
Thanks for your help.
This question cannot be answered as asked without knowing the exact definition of your time dimensions.
An approach which might be worth considering if your MDX knowledge is little, but you have some SQL knowledge and if your requirements can be fixed to just the month level as you described, could be the following, which does the main calculations already when loading the cube, and not at query time in MDX:
Add a column 'months_from_creation_to_resolution' to your fact table, possibly just add this as a column in the view you may already use on the fact table. This column would be 0 if the ticket was resolved in the same month where it was created, 1 if it was resolved in the month after creation, 2 if it was resolved e. g. in May and created in March, etc. You do this calculation using SQL date functions. You would then create a new dimension in your cube from this table, which would have the new column as the only attribute. SSAS has no problem using a table as base for both a measure group and a dimension.
Then, in MDX, the number of tickets resolved in the month they were created would just be
([Measures].[TicketCount], [Fact].[months from creation to resolution].[0])
and those resolved in the month after creation would be
([Measures].[TicketCount], [Fact].[months from creation to resolution].[1])
As a side effect, the query run time would be faster, as the main logic is pre-calculated when loading the cube.
Let's say I have a date dimension and from my business requirements I know that the most granular I would need to go is to examine the specific day of the month that an event occurred.
The data I am given provides me with the exact time that an event occurred (YYYY-MM-DD HH:MM:SS). I have two opitons:
Before loading the data into the date dimension, slice the HH:MM:SS from the date.
Create the time attributes in my date dimension and insert the full date time.
The way I see it, I should go with the option 1. This would remove redundant data and save some space. However, if I go with option 2, should the business requirements ever change or if my manager suddenly wants to be more granular I wouldn't need to modify my original design. Which option is more commonly used? Are there more options that I did not consider?
Update - follow up question
I receive new data every month. If I used a pre built date dimension with all the dates would I then need to run my script every month to populate the table with new dates of that month or would I have a continuous process where by every day insert into the table one row, which would be that date?
I would agree with you and avoid option 2. A standard date dimension table is at the individual date level. If you did need to analyse by time of day, you could create an additional time of day dimension at the level of a second in a single day, and link to that from your fact table.
Your date dimension should be created by script automatically, rather than from the dates that events occurred. This allows you to analyse across a range of events from other facts, and on dates where no events occur, using a standard, prebuilt dimension.
I would also include the full date/time stamp as a column in the fact table, along with the 'DateKey' to the dimension table. This would allow you some visibility/analysis of the timestamp, you would not lose the data, and would still allow you to analyse by the date dimension.
Update - follow up question
Your pre-built date dimension (the standard way of doing it) would usually contain some dates in the future. There's no reason not to, for example, include another 5 years of dates in the table. But if you'd like it to gradually grow over time, you could have a script that is run once a day, once a month, or once a year to add new dates. Its totally up to you! There are many example scripts for building date dimensions- just google date dimension script. They exist for the language of your choice, e.g. SQL, C#, Power Query, etc.
I have a fact table housing different granularity (date grain)
Monthly
Daily
The month data can be accessed by filtering by end of month date or using YYYYMM date format. In OBIEE RPD repo, the fact is set to LAST Aggregation.
I want to perform Year to Date analysis. And I want to sum only month end dates.
Using function TODATE(Measure), it tends to sum up all the data through out the month e.grain
Date Amount YTD TODate(Amount)
31/01/2106 100 100
28/02/2016 200 300
14/03/2016 50 350*
31/03/2016 100 450
I want YTD to ignore 50 and return 400, so also any other dates that falls within any month. And if if I Select 14/03/2016 I want 350 to return.
Thanks.
Alter the table to add a flag, something that flags Y if the record is at the specified monthly grain, and N if the record is not at the specified monthly grain.
In the logical layer, create two distinct LTSs with the first filtering on the flag for Y. This will be where you will calculate and source all your to date measures. The second LTS can either be filtered to N, or can be left to all the data depending on what you want to do with it.
The performance increases should come from the fact that any month measures you build off that monthly LTS will only hit records flagged as month, and will bypass all that other data that is not relevant. So if a user runs a report only asking for monthly measures, the query will automatically filter to that specific data.
What will happen is if a user selects your to date measure and a specific date measure on the same report, OBIEE should fire off two separate queries to get the data and stitch together based on common dimensions.
Could someone create this in the front end? Probably. You would have to do some sort of PERIODROLLING function, and tell it to aggregate at the month level, but I am afraid it may still roll those days up into a larger than desired number. A TODATE function will not work here.
I need to get timestamps from Axapta-tables in TSQL, without timezone and / or daylight-bias-offsets for each time, eg from table JMGABSENCECALENDAR.
Taking this as initial approach, and regaring this, it works for current time. But reading data from the table referring to other timestamps, the solution provided in the second link doesn't get the information about daylight to the specified time.
For example:
I add an absence for today ( 2012-01-07 ).
Now, using SSMS, reading this dataset leads to
starttime = 2013-01-06 23:00:00.000
and endtime = 2013-01-07 23:00:00.000
That's ok, and I can use
DECLARE #UTCOffset SMALLINT
EXEC master..xp_regread
'HKEY_LOCAL_MACHINE',
'SYSTEM\CurrentControlSet\Control\TimeZoneInformation',
'ActiveTimeBias',
#UTCOffset OUTPUT
SELECT DATEADD(MINUTE, #UTCOffset, GETDATE()) AS UTCTime
to remove offset. This works fine on actual dates, but what's the right way to remove offset for past or future times, eg 2012-07-01 ?
Here, the offset is 120 minutes, because of summertime. Reading Reg-Value only returns current offset.
The task has to be solved in TSQL 2008.
I had a same problem, but it was in a complete different setting. I had nothing to do with axapta.
However, i had the problem that i had to know the UTC offset of different times. The tricky part here is the fact that different countries use a different approach towards daylight saving times, and therefor a difference in the offset may occur for different countries at the same time.
What i did was to create a lookup table where i put in the dates that UTC offsets change, these are known dates. I gave it an offset column so i could easily look up the offset that i needed for a certain date, using the between operator.
It worked for me, maybe this solution can provide you something?
Ps. You don't have to lookup the UTC date offset from out of the registry. Using the function getutcdate() will give you the same ;) Using that inside a DATADD makes it a little more readable ;)
Have fun and i hope i could contribute to your problem...
Just because the daylight savings switch dates change from year to year and state to state, your only viable option is a lookup table.
You can find the data for example here http://www.timeanddate.com/time/dst/2013a.html
However, you might not have to maintain that list yourself. timeanddate.com has a calculator on their site. Others offer similar services. You could look for a public API and then use a few lines of CLR code to call that API from your database.
Or you could use such a service to maintain your own copy of that data. Having your own lookup table will be by far the fastest solution.