Skip navigation

Letters to the Editor - 22 Aug 2007

Date/Time Conversions Code Correction

Thanks to Susan Perschke for her great article, "Automate Date/Time Conversions" (March 2007, InstantDoc ID 94954). I just finished a project where I had to do exactly what Susan described in Listing 1 and created a uniqueness database file (UDF) that does the same thing. From her article, I thought I might create a couple more handy date/time-related UDFs. I ran into a snag with her sp_format_dt. The "set @ result = convert(char(20), convert(datetime, @dt, @code_in), @code_out)" statement failed for me. After consulting the SQL Server documentation, I believe it specifies that you can use only the Style parameter when converting to a STRING type (nchar, nvarchar, char, varchar, nchar, or nvarchar data types). The part "convert(datetime, @dt, @code_in)" doesn't seem to work. Instead, what I get is an error: Conversion failed when converting datetime from character string. Am I right about this, or am I missing something about this statement?
—Jack Rosa

Thank you for the compliment, Jack, and for the feedback. As sometimes happens, the original code was modified during the editing process, and I have to confess that I dropped the ball on retesting the code before the article went to print. We've corrected the code back to the original for the stored procedure, and you can access it in the online article's downloadable .zip file. I'm happy to hear that you've achieved good results with this method.
—Susan Perschke

A SharePoint Survival Guide for SQL Server Admins

Lately, I've been looking for information on the topic "SharePoint for SQL Server admins." I run the SQL Server systems in my shop. I'm not a SharePoint developer or administrator. But under the hood, most of the SharePoint data is on my servers—and SharePoint is no ordinary app. Once I realized that it needed to be able to create and destroy databases, I knew it needed its own instance—usually database owners (DBOs) don't get that permission. But these are databases of databases. Recently, I tried to move them to a new SQL Server instance by using detach/copy/attach. We still don't know why that ended in disaster. When we gave up and reattached the original server to the untouched original files, that didn't work either. Neither our SharePoint admin nor I know the right answer to "best way to back it all up." I want to use my usual full/differential/logs cycle. He thinks he should be using stsadm and copying database dumps across the network. I know—it depends on what you'll need to restore. Still, we'd like a better way to make those decisions.

So, a SQL Server admin supporting SharePoint needs to know a fair amount about SharePoint, without becoming a general expert in SharePoint administration or development. I could sort through the general SharePoint admin courses and books, but I've got 137 other databases on three different platforms to look after, too, so I don't want to spend more time on SharePoint than I need to. And I really would like to hear from someone who doesn't need to be told what a stored procedure is but might have little notion of what a Web part is. Does one of your gurus have the background and desire to write such an article?
—Roger Reid

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.