A notification pops up on your system: you have a new, red exclamation point, high-priority email. Before you can even read it, your phone rings. It’s your boss. “I just emailed you. We just discovered that column X in our database contains restricted PII that we can’t be storing. The DBAs are deleting the column as we speak. Please be sure it is gone from reports and your system immediately!” You open Microsoft Power BI Desktop, hit refresh, and the column disappears from the dataset because has been removed from the server; then you save the file. But is column really gone, or could there be remnants of its data left on your system?
A prospective client asks you to look at a PBIX file. When you’re done, to minimize liability you don’t want someone else’s data or credentials left sitting on your system, so you delete the file. Are its contents and associated credentials really all gone?
A coworker needs advice on a report, handing it to you on a thumb drive, with the file marked read-only. You open the PBIX file directly from the external drive, give your thoughts then close the file without saving it. Since the drive was external and the file read only, the file was contained exclusively on the flash drive—or was it?
Whether for security purposes, regulatory compliance’s sake, good business practices or liability management, having a sense for whether and, if so, how widely, Power BI spreads report data on your system is a good thing.
Last night, I had the privilege of sharing a lightning talk at the OKC SQL Server User Group (OKCSQL). This 17-minute presentation touches on four scenarios where the way columns are returned by
SELECT might not match what you expect.
When you write
SELECT statements, you probably have expectations like:
SELECT * returns all columns in the referenced object(s).
- Each column is returned in a separate column.
- Each column returned in visible in the result set.
However—at least in the world of Microsoft SQL Server/Transact SQL (T-SQL)—these assumptions aren’t always true.
The resultset grid shows all columns sent by the server, right? Not always! Under certain circumstances, Microsoft® SQL Server® transmits columns that weren’t referenced in the
SELECT statement and that don’t show up in tools like SSMS.
How many columns does the below view return? Four seems like the obvious answer but it’s only sometimes correct. This view sometimes returns four columns—and other times returns nine!
CREATE VIEW dbo.EmployeeSummary AS
dl1.MonthName + ' ' + dl1.DayString AS Birthday,
dl2.YearString AS EmployedSince
FROM Employee e
JOIN UserAccount u ON e.UserName = u.UserName
JOIN EmploymentHistory h ON e.SSN = h.SSN
JOIN DateLookup dl1 ON h.HireDate = dl1.Date
JOIN DateLookup dl2 ON u.Birthdate = dl2.Date;
The extra five columns (shaded in yellow, below) are returned as hidden columns. They won’t appear in most query tools, yet the data they contain still crosses the wire and can be accessed programmatically on the client-side.
It depends. 🙂
Tabular Data Stream (TDS)—the protocol used for client-to-Microsoft® SQL Server® communications—gives both client and server three options in regards to encryption: require, support or doesn’t support. Whether SQL Authentication credentials are encrypted depends on which encryption options are in use.