Press "Enter" to skip to content

Day: January 4, 2016

Use Parentheses Wisely

Published 2016-01-04 by Kevin Feasel

Jen McCown plays around with the AND and OR operators:

Specifically, how is it evaluated when your where clause says “WHERE This AND That OR Something AND that”, without any clarifying parenthesis?

Let’s play around with this. The simplest test scenario is a SELECT 1. If I get a 1 back, that means my WHERE clause evaluated to true, right? Right.

Parentheses should clarify statements.  If I see an “AND” and an “OR” in a WHERE clause, I want to see parentheses, even if you’ve gotten it right.  It’s too easy to misinterpret precedence.

1 Comment

Think About Installation

Published 2016-01-04 by Kevin Feasel

Dave Mason implores us to think of the installation:

Every tsql command in your SQL script(s) has the potential to fail. It’s important to catch and handle tsql errors so that they don’t cause the entire installation to fail. This will require a lot of defensive, resilient, fault-tolerant coding on your part. Here’s an example for creating the database. Note the emphasis on permissions, which I touched on in another post.

This is important advice if you send installation scripts to customers (even if you’re using a packager to generate an install EXE).

1 Comment

Capturing Blocking Information

Published 2016-01-04 by Kevin Feasel

Erin Stellato shows us how to capture details when processes are blocked:

To view the output from extended events you can open the .xel file in Management Studio or query the data using the sys.fn_xe_file_target_read_file function. I typically prefer the UI, but there’s currently no great way to copy the blocking report text and view it in the format you’re used to.  But if you use the function to read and parse the XML from the file, you can…

If you can’t buy a tool which monitors long-term blocking, you can still build it yourself pretty easily.

Comments closed

Asking The Right Question

Published 2016-01-04 by Kevin Feasel

Buck Woody argues that the hardest thing about data science is asking the right question:

When I started down the path of learning Data Science, I was nervous. I have to work hard at math – it’s a skill I love but one that does not come naturally to me. I was nervous because I thought the most daunting task I would face in Data Science waslearning all the algebra, statistics, and other maths I would need to do the job.

But I was wrong.

Math isn’t the hardest thing in Data Science. Actually, since it’s so mature, and documented, and well-known, it’s quite possibly the easiest thing to conquer in the skillset. No, the hardest thing about Data Science is asking the right question.

I’ll lodge a bit of a disagreement here.  I’m okay with the argument that asking the right question is the toughest part, but the math’s not particularly easy either…  Knowing when to use which distribution, which model, and which parameters requires a definite amount of skill.

Comments closed

Multi-Tab Reports With R And jQuery

Published 2016-01-04 by Kevin Feasel

Matt Parker shows us how to create multi-tab reports using jQuery UI and R data:

But R is also part of an entire ecosystem of open tools that can be linked together. For example, Markdown, Pandoc, and knitr combine to make R an incredible tool for dynamic reporting and reproducible research. If your chosen output format is HTML, you’ve linked into yet another open ecosystem with countless further extensions.

One of those extensions – and the focus of this post – is jQuery UI. jQuery UI makes a set of JavaScript’s most useful moves available to developers as a robust, easy-to-implement toolkit ideal for adding a bit of interactivity to your knitr reports.

Generating a page from R is one of those good ideas that I probably don’t want to see in a production environment.

Comments closed