It's getting close to the end of summer, at least for my family. The kids start school activities and sports on Aug 11, so we're just a few weeks away from me starting to wake up early each day and move them around. It's been an amazing summer for me, one that I never would have imagined at the start of the year, and we still have a couple more activities planned.
Most of my summer was my incredible sabbatical, which was the experience of a lifetime. My family had a few other events, and we've got a short vacation planned before school starts. While I'm sure most of you don't have anything like a 6 week adventure away from work, I am hoping you had some memorable times. With that in mind, I wanted a poll away from work this week.
What fun things have you done this summer (or this year) away from work?
Many of you have kids, or at least plan some summertime holiday. We've seen traffic go down at SQLServerCentral, so we know at least a good percentage of you haven't been diving into work each day and continuing your education. I suppose some of you have been working very hard on a project and haven't had time to take breaks to learn something, which is a good problem to have. At least in the short term.
Perhaps you have exciting plans coming up, but in either case, let us know what was a fun break from work this summer.
Checking program code into source control is a daily ritual for most developers, but versioning database code is less well-understood. Grant Fritchey argues that getting your databases under source control is not only vital for the stability of development and deployment, but it will make your life easier when something does go wrong. More »
During a transaction, data is written to the log cache so that it’s ready to be written to the log file on commit, or can be rolled back if necessary. When the log cache is being flushed to disk, the SQL Server session will wait on the WriteLog wait type. If this happens all the time, it may suggest disk bottlenecks where the transaction log is stored. More »
SQL Server Execution Plans shows you what's going on behind the scenes in SQL Server. They can provide you with a wealth of information on how your queries are being executed by SQL Server, including: Which indexes are being used, and where no indexes are being used at all. How the data is being retrieved, and joined, from the tables defined in your query. How aggregations in GROUP BY queries are put together. Grab your copy today from Amazon!
Yesterday's Question of the Day
Evaluate the following statement and choose the most correct answer:
The staging process for importing data with Master Data Services (MDS) in SQL Server 2014 has changed since 2008 R2. You must rewrite 2008 R2 processes or they will fail.
Answer: This is incorrect because the staging process in 2014 has changed but the 2008 R2 processes will still work
According MSDN, the staging process in 2014 has changed but the 2008 R2 processes will still work.
By putting the script in an query that can be executed, it lets me pass database names to it, without having to create the proc in each DB. Feel free to play with the defaults, but these seem to work for us. Because these are very critical online systems, I have decided to keep the ONLINE=ON setting by default. But because there are tables that may have column types that can't be built online, such as text or XML, then a TRY/CATCH block switches it to OFF.
Below Update statement is not working! any Idea why
- create table #tmpcopylibrary
insert #tmpcopylibrary select 1,999
SET Value = isnull((select top 1 Value from #tmpcopylibrary
where dataid = TableA.dataid), 0)
XML to file
- I have a query that, when run in SSMS with 'Results to Grid' selected, provides a link (in the grid)....
Unable to get Value from XML
- <?xml version="1.0" encoding="utf-8"?>
<xs:schema id="NewDataSet" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:UseCurrentLocale="true">
<xs:choice minOccurs="0" maxO
This newsletter was sent to you because you signed up at SQLServerCentral.com.
Feel free to forward this to any colleagues that you think might be interested.
If you have received this email from a colleague, you can register to receive it here.