Since I last blogged about Denali, Microsoft has announced the official name for this version of SQL Server to be....(drum roll). SQL2012. Ok, ok. I'm pretty underwhelmed too but hey ho. Project Crescent now has the rather grand title of Power View and Juneau has the slightly less impressive Data Tools.
More exciting and interesting though are the changes to the Editions and also the licensing costs, in particular the introduction of a BI edition and the move to per core licensing. You can read more about this in this blog from Geoff Hiten.
I also came across this blog from the SQL Express guys which talks of the new LocalDB edition aimed at Developers. A lightweight database server with less management overhead than a full SQL Express edition. Nice.
Saturday, 26 November 2011
Denali: Now gets a proper name!
Friday, 18 November 2011
Admin: Execute Folder of Scripts
Here's a simple powershell script to loop through a directory and execute the sql files contained within:
ADD-pssnapin SqlServerCmdletSnapin100
$ServerName = "MySERVER"
$Db = "MyDB"
$scriptDir = "c:\FileDir\"
$files = gci $scriptDir* -include *.sql
foreach ($file IN $files)
{
Invoke-Sqlcmd -ServerInstance $ServerName -DATABASE $Db -InputFile $File
}
Tuesday, 8 November 2011
SSRS: Use Stored Procedures in Datasets
I'm a big believer in using Stored Procedures (or at the very least, UDFs) for your Reporting Services datasets. and separating your presentation layer from your data layer and moving the SQL code away from the RDL.
The benefits of this are that you as long as the meta-data of your Stored Procedure stays the same, then you able to modify and enhance your SQL code without having to touch the RDL. You essentially abstract away the source code from the report.
Perhaps you're improving performance by moving to JOINs from cursors, extended the business logic to only return rows that meet new criteria or simply doing a refactoring of SQL code to standardise your table names. All of these don't affect the presentation layer and having them reside as Stored Procedures on the database, gives huge maintenance benefits.
Other advantages include having all your T-SQL held in the one place and knowing that you are aware of the impact of any changes without having to worry about dependancies elsewhere. Also, you will often be re-using code (eg for parameter datasets) and using a single stored procedure helps reduce duplication of effort (and probably performance benefits too).
Of course, there are downsides to this approach. If you need to introduce a new parameter to a report (which is passed to your dataset) then you have to change both the RDL and the stored procedure. I can see this being a slight irritation as you now have 2 deployments whereas holding the SQL code "inline" means a simple upload of the new report.
For me though, the former approach still wins and I advocate using Stored Procedures for Reporting Services datasets. I've been experimenting recently with putting Stored Procedures used for Reports into their own schema (acting as a namespace) although I can't categorically say whether this has been a success or not (Jamie Thomson (Blog | Twitter) has an interesting blog post which touches on Schema usage here).
Labels:
Functions,
RDL,
Report,
Reporting Services,
Reporting Services 2008,
SQL,
SQL Server,
SSRS,
Stored Procedure,
T-SQL,
T-SQL Tuesday,
udf
Thursday, 3 November 2011
T-SQL: Why have NULL bit fields?
I was asked the question the other day, why SQL Server allows NULLs for the BIT datatype. What you need to bear in mind is what NULL represents - a value which is unknown - and, so there are 3 states which you need to cater for. True, False or Unknown.
As is my wont, I like to explain things with analogies and this is no different. Consider a table holding job application details for a job board website.
The key field to note here is of course the BIT field which indicates the success or failure of the applicaiton. Obviously, when a candidate applies to a job, the success of the application isn't known - the candidate has been accepted, nor rejected. Its only at the end of the lifecycle of the application that this field can take on a meaningful value.
Hopefully, this contrived example helps explain just when you might require a NULL bit field.
As is my wont, I like to explain things with analogies and this is no different. Consider a table holding job application details for a job board website.
CREATE TABLE dbo.tblJobApplications(
CandidateID INT,
JobID INT,
DateApplied DATE,
Successful BIT)
-- Application in progress
INSERT INTO dbo.tblJobApplicationsSELECT 1, 1, GETDATE(), NULL
-- Application unsuccessful
INSERT INTO dbo.tblJobApplicationsSELECT 2, 1, GETDATE(), 0
-- Application successful
INSERT INTO dbo.tblJobApplicationsSELECT 3, 1, GETDATE(), 1
The key field to note here is of course the BIT field which indicates the success or failure of the applicaiton. Obviously, when a candidate applies to a job, the success of the application isn't known - the candidate has been accepted, nor rejected. Its only at the end of the lifecycle of the application that this field can take on a meaningful value.
Hopefully, this contrived example helps explain just when you might require a NULL bit field.
Labels:
bit,
data types,
datatype,
Developer,
development,
SQL 2008,
SQL Server,
T-SQL
Subscribe to:
Posts (Atom)