10 Şubat 2010 Çarşamba

SQL Server 2008 R2 Üzerinde Report Builder 3.0 ve ReportViewer Kullanımı

SQL Server 2008 R2 sayesinde Report Builder 3.0 ile tanışmış olduk.
SQL Server 2008 R2 (Server 2008 R2 November CTP) kurulumunu bu adresten yapabilirsiniz. Önceden kurulu olan bir SQL Server 2008 kurulumunuz varsa, bu konuda bahsedeceğim yeni özelliklerden faydalanamama ihtimaliniz çok yüksek. Bu sebeple eski 2008 versiyonlarını kaldırarak R2 versiyonuna geçmenizde fayda var.
Burada yanlış anlaşılmaması gereken önemli bir noktayı belirtmek isterim; verileri alacağınız sunucunuzun versiyonu hiç önemli değil, SQL 2000 veya 2005 olabilir. Datasource olarak ne kullanmak isterseniz kullanabilirsiniz. Kritik olan konu şu; Report Builder 3.0 ile oluşturulan .rdl dosyaları sadece SQL Server 2008 R2 ile gelen Reporting Service üzerinde host edilebiliyor.
Sizde kurulu versiyonu öğrenmek isterseniz; "SELECT @@VERSION" sorgusunda alacağınız bilgilere göre bir kıyas yapabilirsiniz. Örneğin, ben çalıştırdığımda şu bilgiyi alıyorum: "Microsoft SQL Server 2008 R2 (CTP) - 10.50.1352.12"

Bunun yanında SQL Server Management Studio'da açılırken aşağıdaki şekilde bir imaj ile açılmalı.

Sadece Report Builder 3.0 kurulumu yapmak isterseniz, Microsoft değiştirmediyse buradan bu işlemi yapabilirsiniz.

SQL Server 2008 R2 artık kurulu ise konumuza başlayabiliriz.

Report Builder 3.0 ile nasıl rapor oluşturulacağı kısmına burada hiç girmeyeceğim. Benim örneklerimde kullandığım sürüm gene November CTP sürümü.


Raporumuz oluştuktan sonra elimizde bir .rdl dosyamız olacak. Bu dosyayı Reporting Service'e publish etmemiz gerekecektir. Bu işlemi iki şekilde yapabiliriz;
  • Report Builder üzerinden
  • Reporting Services Web Yönetim ekranı üzerinden
Web yönetim ekranı ile yapmak isterseniz, öncelikle uygun adresi bulmanız gerekli. Bunun için Reporting Services'ın yüklü olduğu bilgisayarda;
Başlat > Microsoft SQL Server 2008 R2 November CTP > Configuration Tools > Reporting Services Configuration Manager kısa yolunu açmamız gerekiyor.
Burada karşımıza Reporting Services için kullanacağımız yönetim aracına ulaşıyoruz.
Server ve Instance seçimi ile istediğimi Reporting Service'a ulaşıyoruz. Bu aracın sağ tarafında iki adet URL var. Bunlardan birisi Reporting Services hizmeti veren servisin adresi, diğeri ise raporları deploy etmemize yarayan web yönetim arayüzünün adresi. Biz Report Manager URL üzerinden gideceğiz.
Sunucumuzun adı SQL2008R2 ise, muhtemelen adres "http://localhost:8080/Reports_SQL2008R2" şekilde olacaktır. Buradan "Upload File" diyerek .rdl dosyamızı deploy edebiliriz. İstersek klasörler kullanarak, ileride raporlarımızın artması durumunda daha derli toplu bir görünüm elde edebiliriz.

Web arayüzünden önce Report Builder ile deploy işlemini denemenizde fayda var, çünkü eğer Reporting Services versiyonu uyumsuz ise (R2 değilse) raporları deploy edemeyeceğimizi hiç uğraşmadan anlamış oluruz.

Report Builder üzerinde, Publish Report Parts veya direk Connect to a report server dediğimizde bizden servis adresini girmemizi isteyecektir. Bu adres "http://localhost:8080/ReportServer_SQL2008R2" gibi bir adres olacaktır. Buraya web yönetim arayüzünün adresinin girilmesi sık yapılan bir hatadır, dikkatli olmak gerekli.

Artık raporumuz deploy edilmiş demektir. Bundan sonra geriye bu raporu bir web uygulamasına eklemek kalıyor. Bu kısım oldukça kolay. Visual Studio 2008 üzerinde bir web uygulaması veya web sitesi projesi yaratıyoruz. Design modunda sayfamıza MictosoftReportViewer ekliyoruz (Toolbox üzerinde Reporting sekmesinde bulabilirsiniz). ServerPath kısmına "/RaporAdı" giriyoruz, ReportServerUrl kısmına yukarıdaki servis adresini giriyoruz. Eğer makinaların birbirlerine erişiminde bir problem yoksa raporumuzu görebiliyor olmamız gerekli.

Bu şekilde Report Builder 3.0 ile hazırladığımız, grafiksel olarak zenginleştirilmiş raporlarımızı web uygulamalarında da kullanmış oluyoruz.

9 Şubat 2010 Salı

SQL Sorgularında "IN" - "NOT IN" Kullanımı

sqlservercentral.com'da okuduğum bir yazıyı burada paylaşmak istedim.

Konu sorgularımızda IN ve NOT IN kıyaslamalarını kullanmamız.
Aslında konuyu ikiye ayırmakta fayda var, ilk olarak performans konusunu ele almamız uygun olacaktır. Hemen en önemli kısım ile başlayalım; NOT IN kullanılan sorgularda INDEX kullanılmaz :)

Index'in mantığı gereği, bu indexte olmayanları bul dediğimizde, kayıtların sıralı olmasının bize bir faydası olmayacaktır. Tüm tablonun taranması gerekecektir. Konu ile çok ilgisi olmasada benzer bir durumu daha söylemekte fayda var. LIKE '%KRITER' şeklinde bir arama yaptığımızda Index'imizin bize faydası olmayacaktır. Bunun sebebi Index'lerin sıralı bir şekilde tablomuzda barınıyor olması, biz ilk karakteri bilemezsek bu sıranın bize faydası olmayacaktır. Bunu baş harfini bilmediğimiz bir kelimeyi sözlükte aramak olarak düşünebilirsiniz, fihristi kullanma imkanımız olmayacak, tüm kelimelere teker teker bakmamız gerekecektir.
NOT LIKE, <> gibi kriterlerde de Index kullanımı aynı sebepler yüzünden olmayacaktır. 

Hem NOT LIKE hemde '%KRITER' şeklindeki bir sorguda, SQL motoru tarafından kafamıza şişe fırlatılması ihtimali yüksektir :)

Bu sebeplerden olumsuz kriter kullanımlarımını sadece zorunlu durumlardaki sorgularımızda kullanmalıyız. Sistemi incelerken kontrollü bir şekilde bu sorguları kullanabiliriz. Ancak özellikle raporlarda bu eşitsizlik kontrollerinin kullanımı, ve özellikle büyük tablolarda kullanımı bizi çok ama çok zora sokacaktır. Kesinlikle bu tür kullanımlardan uzak durmamız gerekiyor.

Konunun bu kısmı nispeten biliniyordu, ancak bana asıl ilginç gelen NOT IN kullanımlarında dönen cevapların belirsizliği oldu, bunu ilgili sayfadaki arkadaşımız çok güzel bir örnekle açıklamış aynen iletiyorum.

IN kullanımlarında aslında arka planda şu şekilde bir sorgu çalışmış oluyor "WHERE myvalue = 'A' OR myvalue = 'B' OR myvalue = NULL"
Burada bir OR işlemi olduğundan dolayı, beklemediğimiz bir sonuç ile karşılaşmamız olası değil.


NOT IN kullanımlarında ise arka planda aslında olan 'WHERE myvalue <> 'A' AND myvalue <> 'B' AND myvalue <> NULL “

İşte burada bir AND işlemi var, NULL olan alanlar belirsiz olduklarından dolayı, sorgu sonucunda beklemediğimiz bir sonuç kümesi ile karşılaşmamız olası.

A IS NULL ve A = NULL arasında fark olduğunu unutmamak gerekli. Bir çok kişi bu basit hatadan dolayı saatlerce sorgusundaki hatayı arayabilir -ben çok aradım-.


Buradaki kıyaslama için SET ANSI_NULLS = ON/OFF durumu önemlidir. Uygun olan kullanım genelde ON şeklindedir. Yukarıda yazdığım örnekte bu ayarın ON durumunda olduğunu varsaydım.