January 16, 2012 at 5:10 am
SQL Kiwi (1/16/2012)
Jeff Moden (1/16/2012)
Generating the data with a script that uses NEWID() avoids another problem... backwards compatibility for restores. Here's what happens when someone using SQL Server 2005 tries to restore the Example.bak DB you were kind enough to provide.Certainly. One would probably state version requirements, or provide a zipped 2005 database file (mdf only) or backup. Both of these could generally be restored or attached to any version of SQL Server 2005-2012. I happened to use 2008 R2, and should have mentioned that.
I think you're much more likely to encourage people to test with large data-sets if they have something they can paste into their own test environment and just execute.
January 16, 2012 at 5:19 am
Cadavre (1/16/2012)
I think you're much more likely to encourage people to test with large data-sets if they have something they can paste into their own test environment and just execute.
So provide both, and give them the choice: an exact copy for repeatable results, or a script they can just run, but might get different data, plans, and results.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
January 16, 2012 at 6:22 am
Jeff Moden (1/16/2012)
Generating the data with a script that uses NEWID() avoids another problem... backwards compatibility for restores. Here's what happens when someone using SQL Server 2005 tries to restore the Example.bak DB you were kind enough to provide.
Update: I based my sample on the one you provided, so it contains DATE columns (new in 2008), so there's no way to restore it (or run your script) on 2005.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
January 17, 2012 at 6:14 am
Another thing to keep in mind is that I won't download a .zip file from a source I don't know and trust, and you'd be wise to have the same rule. They can contain malicious code far too easily.
A .txt file or .sql file with a script in it is much less potentially hazardous.
A .bak file with a database backup in it is probably okay. So far as I know, even if one had malicious code in it, there'd be no way for it to auto-execute that, and I'd inspect any executable code objects (procs, et al) before running them.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 17, 2012 at 6:53 am
GSquared (1/17/2012)
A .bak file with a database backup in it is probably okay. So far as I know, even if one had malicious code in it, there'd be no way for it to auto-execute that, and I'd inspect any executable code objects (procs, et al) before running them.
Yep, someone did exactly that on a forum question earlier today. It made the problem much easier to work on. I'd be happy with a backup or mdf file (as the AdventureWorks distribution uses these days).
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply