My latest MSDN column is available in the August issue and called "How Data Access Affects Database Performance". It was inspired by a problem that one of my DBA friends noticed in the database that could only be fixed by changing the data access code.

I noticed that there were two articles in the issue on EDM and, although I'm using native ADO.NET code for examples, I mention how EDM-generated code fits into one of the common cases.

I hope the information is useful.

Categories:
Performance

I really enjoyed speaking at the Portland SQL Server User Group meeting last night about SQL Server security...and I have an update.

We were talking about the supposed inability of auditing to audit usage of sys.fn_get_audit_file, the system function that reads an audit log. Raul Garcia of the SQL Server team had the answer. "For the particular scenario in this bug (sys.fn_get_audit_file), the permission being exercised is SELECT, not EXECUTE, hence the apparent failure to audit usage."

An database audit specification in the master database for SELECT ON OBJECT::sys.fn_get_audit_file BY PUBLIC will audit it, regardless of the "current database" when the function is issued.

Thanks Raul. 

 

Categories:
Security

During a talk about spatial indexes and performance last week, I was surprised by a question about using ANSI-92 JOIN - ON syntax in spatial queries. I'd coded:

SELECT * FROM geonames.dbo.geonames g
JOIN Sample_USA.dbo.Counties c
  ON g.GEOG.STIntersects(c.geog) = 1
WHERE c.ID = 1569

Later I learned that the question was prompted by the following verbiage from the SQL Server Books Online: "To be supported by a spatial index, these methods must be used within the WHERE clause of a query, and they must occur within a predicate of the following general form geometry1 . method_name ( geometry2 ) comparison_operator valid_number".

There phrase "within the WHERE clause" is a bit too restrictive. The query above using JOIN has the exact same plan as this equivalent query using WHERE does:

SELECT * FROM geonames.dbo.geonames g, Sample_USA.dbo.Counties c
WHERE c.ID = 1569
AND g.GEOG.STIntersects(c.geog) = 1

Works just fine, either form uses the spatial index. The reason why folks would be concerned about the EXACT WORDING rather than the spirit of the advice, is that the second part of the BOL sentence IS true; the spatial method must be BEFORE the comparison predicate. That is:

-- This uses the spatial index
SELECT * FROM geonames.dbo.geonames g, Sample_USA.dbo.Counties c
WHERE c.ID = 1569
AND g.GEOG.STIntersects(c.geog) = 1

-- This doesn't use the spatial index
SELECT * FROM geonames.dbo.geonames g, Sample_USA.dbo.Counties c
WHERE c.ID = 1569
AND 1 = g.GEOG.STIntersects(c.geog)

But go ahead and use the JOIN verb, it uses the spatial index just fine. As a matter of fact, if you want parameter sniffing and query plan reuse it should be:

CREATE PROCEDURE GetNamesForCounty (@county_id int)
AS
SELECT * FROM geonames.dbo.geonames g
JOIN Sample_USA.dbo.Counties c
  ON g.GEOG.STIntersects(c.geog) = 1
WHERE c.ID = @county_id

Or call the parameterized query from a database API directly (ie use query parameters rather than variables with parameterized queries). And OF COURSE you usually don't need SELECT * either...

Went through 2 years worth of blog entries looking for comments to approve. Sorry that I've been remiss in doing that. I have to approve every comment "by hand" and we'd been getting a lot of spam comments, so I've been putting it off. I'll approve anything that doesn't look like spam so if you don't see your comment appear right away, write and let me know. And keep those comments coming...

Categories:

Last week I attended my first-ever ESRI conference in San Diego. Although the "star of the show" was version 9.3.1 and the upcoming version 9.4 of the ARCGIS series of products, I most enjoyed the presentations about the new ESRI MapIt product. This product is a collection of tools and toolkits to allow import, preparation, and usage of spatial data in SQL Server 2008.

The tools include:
A data import and encoding tool, Spatial Data Assistant, that enables you to import data from .shp files and ARCGIS Servers. I especially liked that the tool can reproject the data as it imports. You can also geocode address fields with either the ERSI or Bing Services geocoder.

A REST-based service that allows serving SQL Server spatial data. This allows integration with the webpart and the API.

A Sharepoint Webpart that lets you produce layers from MAPIt, ARCGIS Server, or Sharepoint lists that contain lat/long or address data.

The ARCGIS Silverlight/WPF API now allows input from the MapIt service as well as ARCGIS Servers, Bing Maps, and GEORSS. It's used to produce some amazing applications.

I like the product a lot and installed and worked with the evaluation during and after the show. It simplifies staging and producing brilliant looking maps and apps, but also puts all the power of Silverlight at your disposal.

Actually, the "stars of the show" were the users that attended. ESRI users got a great deal of exposure in the plenary sessions as well as the Map Gallery and elsewhere. I got to meet James Fee and Morten Nielsen. Morten is known for his work with Shape2SQL, SharpMap and other utilities and he now works for ESRI on the Silverlight APIs. Good choice on their part. I also made a lot of new friends at the conference, as always.

Of course I had to sing for my supper as well and presented a talk on Analyzing SQL Server 2008 Spatial Indexes as well as a couple of impromptu sessions and demos at the booth. Because ARCGIS can use SQL Server as a geodatabase and products (including MapIt) automatically define spatial indexes during operation, there was a good deal of interest.

Thanks for a fun time...

Categories:
SQL Server Spatial

This month I'll be presenting a session for the Portland SQL Server User Group. I'll be discussing and demonstrating the new security features in SQL Server 2008 with a post-talk Q&A about SQL Server security in general. I've also got some swag to raffle off. See you on the fourth Thursday!

Categories:
Security

Just got a mail message from an old friend who asked why I'd dropped out of sight in the past month of so. I've been in "extended partial vacation mode" for the last month or so and haven't blogged in a while. But I'm "still alive and well" (Johnny Winter was at the Portland blues festival last week, couldn't help the reference).

Next week I'll be at the ESRI user conference catching up on the latest and greatest in the GIS world. On Tuesday, I'll be doing a fairly short talk for the ESRI SQL Server special interest group on SQL Server 2008 spatial performance troubleshooting and also a longer followup talk (with lots of real-world examples) at the Microsoft booth. If you're around, drop by and say hi.

Theme design by Nukeation based on Jelle Druyts