Now comes our first batch of definitions.
- True positive (TP): Positive test result matches reality — the person is actually sick and tested positive.
- False positive (FP): Positive test result doesn’t match reality — the test is positive but the person is not actually sick.
- True negative (TN): Negative test result matches reality — the person is not sick and tested negative.
- False negative (FN): Negative test result doesn’t match reality — the test is negative but the person is actually sick.
Folks get confused with these often, so here’s a useful heuristic: positive vs. negative reflects the test outcome; true vs. false reflects whether the test got it right or got it wrong.
It’s a nice read. The next step, after understanding these, is figuring out in which circumstances we want to weigh some of these measures more than others.
Stretch databases were going to provide “Cost-effective” availability for cold data, and unlike typical cold data storage, our data would always be online and available to query. Applications would not need to be modified to work with the seamless design of the stretch database. Run a query, and the data was there being pulled from the cloud when needed. Streamlining on-premises data maintenance by reducing the local footprint of the data files as well as the size of backups! It was even going to be possible to keep data secure via encrypted connections to the cloud and in theory, make a migration to the cloud even easier.
It was destined to be a major win!
Then the price was mentioned.
Do you know anyone using stretch databases today?
Yeah, me neither.
It’s an interesting workaround with several moving parts.
The result shows 1 test run, 1 test passed, 2 asserts run, 2 asserts passed.
Wait, what? We have prepared only one assert, why does it show two?
The second assert is: “Task Completed: Actual result (Success) was equal to the expected result (Success).“. Great. Where does it come from? Let’s find out.
This is a nice introduction to the topic; if you fuss about with SSIS packages, you should check this out.
Makes perfect sense, right? This is a basic use case and a good application for simple KPIs; with the one minor caveat that POWER BI DOESN’T SUPPORT THIS!
This topic has become a bit of a soapbox topic for me because it’s a capability that, in my opinion, is a very obvious gap in the Power BI feature set. After unleashing my rant, I’ll demonstrate a solution a little further down in this post.
Both the rant and the workaround are interesting enough to read, so check them out.
Dataset Parameters are a way to bring some sort of dynamic into your Power Query datamodelling in Power BI. For my blog post about Modifying Parameter values in powerbi.com I was looking for a way to display the value of a parameter inside a Power BI report.
In this blog post I would like to show you the steps that are required to bring your parameters to your field list – and as a consequence – into your Power BI report.
Read on to see how to do this.
Take a moment to breathe, this is a loaded update.
The March Public Preview release is focused on improving our Extensibility story and continuing to address top GitHub issues. This includes enabling Extension Manager, improving the Manage Dashboard experience and providing a couple Insights extensions. Please see the following details.
Enhance the Manage Dashboard extensibility model to support tabbed Insights and Configuration panes
Dashboard Insights extensions for sp_whoisactive from whoisactive.com and a Server Reports example
Extension Manager enables simple acquisition of 1st-party and 3rd-party extensions
Add additional Extensibility APIs for connection and objectexplorer management
Community Localization open for 10 languages
Continue to fix important customer impacting GitHub issues
There’s some nice stuff in this release, but the big story is around extensibility.
DATETIMEOFFSETworks the same way as the
DATETIME2data type, except that it is also time zone aware. It is formatted as
Got all that?
YYYYrepresents a four-digit year,
MMis a two-digit month between 1 and 12,
DDis a two-digit day between 1 and 31 depending on the month,
HHrepresents a two-digit hour between 0 and 23,
mmis the minutes between 0 and 59, while
ssis the number of seconds between 0 and 59. Once again,
nrepresents between zero and seven decimal places in a fraction of a second.
The main difference from
DATETIME2is the time zone offset at the end, which is the number of hours and minutes as an offset from UTC time.
Read on for more. I generally don’t use this date type much, preferring to stick with
DATETIME2 and saving data as UTC.