This blog posting is meant to bring attention to the fact that I'm doing a preconference talk, "A Day of SQL Server Security" at TechEd 2010 in New Orleans in June. OK, the TechEd folks asked me to publicize it. I'm also doing two breakout sessions, one on "Entity Framework and LINQ2SQL vs. Stored Procedures", and the other on "Integrating Microsoft SQL Server Event Tracing with OS-Level Events and Database Client Events".

Although I've done individual topics of SQL Server Security before (e.g. Auditing, at TechEd Europe 2009) you might be saying to yourself, "this Beauchemin guy is known for database development, what's his background in security anyhow?". Well, I did write the "SQL Server Security Best Practices Whitepaper" for SQL Server 2005. But there's a better story.

In 1992, I made my one-and-only foray into the world of startup companies, when I joined (as employee #2) a company called Open Computing Security Group (OCSG). This company eventually grew and changed its name to CyberSafe, and it's still around today. At "the beginning" we concentrated on Kerberos software, releasing commercial versions of Kerberos for 5-6 Unix variants and Kerberos clients for Windows (3.1) and Mac. This included SDKs, like the GSSAPI, and clients like klogin/klogind. My first Kerberos port was targeted at the NeXT computer.

The new company was going strong and, in addition to the products, we did security audits and taught classes on Kerberos protocol and implementation. The very first class I ever taught was on Kerberos; students seemed to like it, although I immediately went back to being "that geek in the corner who wrote code, and spoke to no one". ;-) Other classes came along post-OCSG.

When Kerberos R5 was released, I was asked to brainstorm a list of products where Kerberos could be integrated. I came up with about 25 ideas (probably not new ideas, but they were new to me) including using Kerberos for database authentication/authorization and using a database as a repository for the KDC. Eventually, I split with the company as it grew.

I've always had a fondness for computer security ever since. And I've been implementing, studying, and teaching anything to do with SQL Server security. Hence, the preconference talk. Be you DBA, developer, architect, or anything in between, I think it will be worth your while.

Last week I did a talk at SQLConnections on SQL Azure Database and Data-Tier Applications (DAC). At the time (it was the day of Visual Studio 2010 launch), I explained that conference abstracts had to be submitted 6 months ago. At the time, because of some coincidental feature correspondence (e.g. the DAC whitepaper suggests only using DAC deployment on databases of 10gb or less; 10gb is the current maximum size of a SQL Azure database) I'd actually thought that DAC and Azure were "joined at the hip" and that DAC might already be used in the cloud (internally) for SQL Azure deployment.

It isn't. In fact, neither DAC nor SQL Azure Database supported each other. *Until last week*. At the VS2010 launch, the other DAC talk (by the team) said Azure would be supported as a development/deployment environment. But, except for "import from existing database", even the RTM VS2010 didn't work with SQL Azure.

Imagine my surprise on returning home to see this blog posting by the SQL Azure team. As of last Friday, SQL Azure enhancements "enables deployments of database applications directly from SQL Server 2008 R2 and Visual Studio 2010 to SQL Azure for database deployment flexibility". So, it does hook up, after all.

DAC is a pretty controversial feature because in V1, it only supports a subset of database objects and deployment via a
"new database-copy data-rename databases" funtionality. So, its not for everyone. But, at both talks, attendees seemed to understand the target audience, the "departmental database application", the "600th database application" in a large company, the ones that usually have no DBA support because DBAs are busy with 24x7 line-of-business OLTP apps. If you've ever worked in a big company where database and software development is not the main business of the company (ie, the main business is manufacturing cars, or banking, not developing software), you can grok what exactly what a "departmental application" is.

The attendees got it. When I asked at the end of my talk if, because there are customers for it in the present, the DAC ought to be postponed until it would work with all DBMS apps, I only got 1 taker (for postponed) out of 100. Not so controversial after all.

Now, to see exactly how DAC and Azure work together. As of Azure on Friday, Apr 16.

I did a few demos in the spatial visualization talk at SQLConnections using the AdventureWorks 2008 data. The Person.Address table is all geocoded and so I did a quick map in SQL Server Reporting Services 2008 R2 using individual addresses. Followed up later in the talk with addresses using ESRI's MapIt product, their Spatial Data Service and nice Silverlight controls. Both demos were projected over maps; I used both Bing Maps and a simple ESRI ARCGIS Server map.

As I zoomed and panned over the maps (SSRS 2008 R2 can zoom and pan during design time; ESRI controls allow interactive zoom and pan) some folks in attendence noticed that the street addresses from AdventureWorks 2008 don't correspond to "real" street names. Other folks told me they had problems using other geocoders with the AdventureWorks 2008 data.

The reason is pretty simple. Although the geocoding gets you to the right city/state, the actual addresses are "fake", aka, test data. So don't expect perfect street correspondance with real streets and test data. And...no, it's not a bug in your geocoder.

I had a great time at SQLConnections last week, and got to talk to a lot of the attendees and speakers during lunches and breaks. It was interesting talking about some controversial topics (like Entity Framework/TSQL or the Data Tier Application) and I hope folks got enough information to make up their own mind. And I hope the folks who attended saw some spatial visualizations that were beyond the ordinary.

It was especially fun for me to speak about database performance from a developer's point of view at the postconference day. As I said then, I think developers have a better chance to improve performance (by writing database and application code with performance in mind) than anywhere else in the database ecosystem. Hope that statement wasn't controversial by the end of the day.

The demos are now posted on the SQLskills website. Hope you'all had as good a time as I did.