Chris McKenzie's Blog

Thanks, I'll look into making that same class.

And I agree. I'm not a DBA and yet I find the number of questions during a developer interview are database questions, some involving DTS packages, replication, backup jobs, etc. I mean I know how to do those things, but not off the top of my head....

I am not a DBA either but if you need to update the statistics by executing sp_updateStats there might be something wrong with the properties of the indexes as updating the stats should be the responsability of the SQL Server there might be however some rare occassions where you want to be in control of the update of the stats but not for regular use. Ask your DBA or if you have access check the indexes of the tables for the options automatically update statistics.

That's the whole problem. We don't have a DBA. I guess we do if you count me, since I'm the person responsible for developing and maintaining the database schema; but we don't have a person who's career focus is on databases, and knows how to fine tune them to get the best performance out of them.

I'm learning an enormous amount about SQL Server. But I still think if I had my way, I'd spend my time on the coding side of things.

As a side note: I've never actually worked at a place where they have separate DBA's and developers. <tongue in cheek>Do they actually exist? </tongue in cheek>

If the problem was due to out of date index statistics why would there be any differences when executing the query in query analyzer or a client application? Sounds a little bit odd but then I am not a DBA either.

Aye, that struck me as weird too. But I verified it 6 ways to Sunday. I even ran both queries through the Sql Profiler. The query in Query Analyzer had about 8000 reads, but the one running in the app had about 130,000 reads. The query text was identical though. I'd be interested in learning how that happened if anyone knows.

"I've never actually worked at a place where they have separate DBA's and developers."

I'd hate to work at those places then ;-). Most of the gigs I've worked have had a very clear distinction between DBA's and Devs...quite simply put I wouldn't want devs (with our wreckless nature) in charge of production DB's.

They way I see it is this: Devs are in charge of A) coming up with the schema B) writing sprocs/functions/etc C) writing tests against the db whereas DBA's are in charge of A) administrative tasks like scheduling backups/defining security/etc B) monitoring the db for performance issues C) cleaning up whatever messes users/devs make on the db D) pretty much any issues w/ *production* databases. The roles are very much seperate in most IT departments. As they should be.

> I also added a DBMaintenance object to my application class so that I can update statistics whenever the need arises.

Do you think it is a good idea to allow your client code execute such low-level db stuff?

Yes I do because this app/db is something that we deploy as an intranet solution to our customers. Our customers by and large do not have an IT staff, and will need to be able to manage their data without hiring expensive technical people. We provide a means to do backups other periodic data maintenance already. We do all of this through our app.

To put the point another way: if the customer runs into the problem that I did, they would call customer service. Customer service would be unable to resolve the issue, and they would call... ME. So, if I put a troubleshooting screen in the app they can try all the standard things I would try without having to call us.

Comments, criticisms?

Pingback from  I'm not a DBA