SSRS Türkçe Karakter Sorunu

Reporting Services ile bir proje yarattınız, dataset'i oluşturdunuz, design'ı yaptınız fakat preview ettiğinizde bir hata alıyorsunuz. Hatayı google'da forumlarda araştırdınız fakat bir çözüm bulamadınız. Tekrar tekrar kontrol ediyorsunuz, dataset'te ki sorgunuz winsql yada başka bir sql platformunda çalışıyor, layout'ta da bir problem yok. Connection'da "test connection succeeded" diyor.  Solution ismi ve rapor ismine bakın, eğer türkçe karakter varsa sorun odur, sql server 2005 "türkçe karakter kullanmayın" diye bir uyarı vermez fakat sorun burada. solution'ı tekrar oluşturun ve kesinlikle rapor isminde türkçe karakter kullanmayın. Yoksa forumlarda hatayı bulmak için saatlerinizi harcarsınız :-)

SSIS'de Aggregate Transformation'ının Kullanımı

Elinizde bir müşteri tablosu olsun, bu müşterilerin bilgilerinin arada sırada güncellendiğini ve son güncelleme tarihininde ayrı bir satır olarak tutulduğunu düşünün. her müşteri için son güncelleme tarihinindeki bilgileri almak istiyor olun.
Ya da apayrı bir case düşünelim: satışlar tablosunda müşteri bazında yapılan her satış tutuluyor olsun ve sizde müşteri bazında toplam satışı alıp bir tabloya yazmak istiyor olun.Her iki durumda da kullanacağınız araç Aggregate olacaktır. Aşağıdaki şemaları bir inceleyin, Agregate ile  max, min, sum, average vs yapma şansınız var. aslında ole db source üzerinde "select a,b,sum(y) from x group by a,b" sorgusunu yazarakta aynı sonuca ulaşabilirsiniz fakat bu aracı kullanmak size ekstra performans sağlayabilir. Performans testi yaparak kararınızı verebilirsiniz.

Sql Server Sample Database (AdventureWorks)

Sql server ile ilgilenen herkes AdventureWorks veritabanını bilir. Sql server 2005 ve 2008 versiyonlarında Northwind yerine gelen örnek bir veritabanıdır. Kurulum esnasında (eğer örnek database'i kurmayı seçerseniz) otomatik olarak gelecektir. Fakat full kurulum yapmadığınız durumlarda bu veritabanına sahip olamayacaksınız. AdventureWorks ve diğer örnek veritabanlarını internetten indirip kurma şansınız var. Google'dan kolaylıkla aratıp bulabileceğiniz .msi setup dosyasını indirip kurduğunuz da AdventureWorks veritabanının C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data  klasörüne kopyalandığını göreceksiniz. Hem primary veritabanı hem de log file'ı orada olacaktır. Sql server management studio'da refresh yaptınız ve o da ne AdventureWorks veritabanı ortada yok :-)) bu bir sorun değil. bu şekilde netten primary ve log veritabanını alıp ilgili klasöre kopyaladıktan sonra yapmanız gereken bir işlem daha var. Management studio'da database sekmesi üzerinde sağ tuşlayıp "Attach" seçeneğini tuşluyoruz. karşımıza AdventureWorks database'i gelecektir. ok deyip tekrar refresh diyoruz ve doya doya adventureworks'ü kullanıyoruz :-)

SSIS Job'larının zaman yönetimi

SSIS ile paketlerinizi oluşturdunuz ve bu paketlerden bir yada daha fazlasıyla bir Job yarattınız. büyük ihtimalle çeşitli zamanlarda çalışan schedule edilmiş bir çok job'ınız vardır, Tabi eğer veriambarına önem veren büyük bir kurumsal firmaysanız. Bu jobların çalışma saatleri gerçekten çok çok önemlidir. başıma gelen bir olayı anlatacağım : 2 job aynı saatte başlıyordu, biri müşterilerin bilgilerini veriambarına alırken  bir diğeri ise ambardaki müşteri bilgilerinden faydalanarak poliçe dosyalarını update ediyordu, 2 job'da saat 21:00'da ayağa kalkıyor. kısacası joblardan biri ambarda bir tabloyu doldururken  diğer job ambardaki bu tablodan bilgiler okuyor. 2. bahsettiğim job'ın başlangıç ile bitişi arasında 3 saat 29 dakika var. saat 21:00'da ayağa kalkan bu job'ın saatini 20:45'e ayarladım. çok ilginç (aslında normal) bir şekilde başlangıç bitiş arası 13 dakikaya indi. inanılmaz değil mi. bugüne kadar sql optimizasyonu ile uğraşırken bakmam gereken tek yer aslında job'ların saatleriymiş. mümkün olduğu kadar birbirleriyle çakışmamasını sağlamak bana 3 saat kar sağladı. eğer bir veriambarınız varsa çalışan job'larınızın başlangıç bitiş saatlerini kontrol etmenizi ve buna göre işlerinizi yönetmenizi öneririm

Veri Ambarı'nın faydaları - 2

Şirketler gün içerisinde bir çok operasyonel iş yaparlar. Muhasebe departmanı yevmiye kayıtları oluştururlar  fatura keser, Satış destek satış rakamlarını sisteme girer, insan kaynakları maaş bilgilerini oluşturur, müşteri hizmetleri tahsilatları kaydeder ve CRM ile ilgilenir vs vs vs. sonuç olarak şirketin yaptığı tüm işlemler gün boyunca bir ya da birden fazla veritabanında saklanır. gün içerisinde bu veritabanlarına insertler yapılır, delete ve update edilir. bu bahsettiğimiz veritabanları operasyonel veritabanlarıdır. büyük bir kurumsal şirket olduğunuzu düşünün ve yönetecek terabaytlar boyutunda bilginiz olsun ve her gün üstüne onlarca gigabyte yeni veri eklensin. Bu sistemden birde departmanların raporlama yaptığınız varsayın. küçük bir firmaysanız problem yok ama bahsettiğimiz gibi büyük kurumsal ölçekte bir firmaysanız gün içinde insert/update/delete yaptığınız veritabanlarında  select ile raporlama yapmamanız lazım. çünkü operasyonel veritabanların temel amacı raporlama değil bilgiyi depolamaktır. Raporlama için veriambarları kullanılmalıdır. bu sayede sisteminize ek bir yük getirmemiş olursunuz. GSM firmalarına güncel borcunuzu öğrenmek için bir mesaj atarsınız. dikkat ettiyseniz bu mesajda şöyle bir vurgu vardır "son 2 günlük tutarınız dahil değildir" . bunun anlamı şirketin size bu bilgiyi gerçek/canlı sisteminden değil  veriambarı sisteminden veriyor olmasıdır. Müşteriye giden bu bilgi mesajı için mevcut canlı sistemini yormamaktadır.

SSRS ile SQL Server dışında bir veritabanından raporlama yapmak isterken "The data extension ODBC does not support named parameters. " hatası

Sql server üzerinde ki veriambarınızdan ya da sql server üzerinden başka bir datamart'tan sorgunuzu yazıp Dataset'inizi oluşturduğunuzda  "@"  ile parametre tanımlama şansınız vardır, Örneğin Select * From Satıslar where Satis_Tarihi = @Tarih  dediğinizde "Tarih" isimli bir parametre tanımlamış olur ve kullanıcı raporu görüntülemeden önce tarih seçme şansına sahip olmuş olur, Bugün öğrendiğim kadarıyla bu sadece Sql server üzerindeki bir database'den raporlama yaparken geçerli.

Örneğin DataSource'unuz AS400-DB2 olsun. bu durumda sorgunuzda @ ile bir parametre tanımlamak istediğinizde " The data extension ODBC does not support named parameters. Use unnamed parameters instead." uyarısı alacaksınız.  Bu sorunu aşmanın bir yolu resimdeki gibi parametre için "@" yerine "?" kullanmak. fakat her bir "?" için SSRS rapor görüntülemede sizden bir değer girmenizi isteyecek.
select * from satislar where satis_tarihi = ? and ise_baslama_tarihi=? gibi bir sorgunuz olduğunda (data source DB2) preview ekranında  parameter1 ve parameter2 göreceksiniz. halbuki "?" işareti yerinde tek bir tarih olacak ve kullanıcının tek bir tarih girmesini istiyorsunuz.

Bu durumda Data'da "..." ya basıp  parameters ekranına geliyorsunuz ve her bir "?" ini tek bir parametreye bağlıyorsunuz. Layout ekranından da report/report parameters ekranından gereksiz parametreleri de siliyorsunuz. artık kullanıcınız tek bir tarih girerek raporunu görüntüleyebilir

Veri Ambarı'nın en temel faydası

Şirket'in günlük faaliyetleri içerisinde canlı sisteme bir çok veri giriş olur. Tahsilatlar, çekler, muhasebe kayıtları, satışlar vs....Tüm bu bilgiler OLTP veritabanlarında tutulmaktadır. aslında biz bu veritabanlarına "Operasyonel Veritabanları" diyoruz. Bir operasyonel veritabanına select cümlesi attığınızda genelde rakamlar görürsünüz. Örneğin satışlar tablosunda acente kodu alanı olsun. bu acente kodu 0-9000 arası değerler alsın. bu durumda 0-9000 arası numaralar göreceksiniz. Normal bir business kullanıcısı bu sistemden bir rapor çektiğinde bu rakamları anlamlandıramayabilir.  0-100 direkt satış ekibi, 101-2000 acente-broker, 2001-9000 banka kanalı olsun. bu sıralamayı bilmeyen bir business kullanıcı bu numaraları adlandırmakta ve acente kanalı bazında raporlama yapmakta zorlanacaktır. Veri ambarları bu noktada yardımımıza koşar. SSIS kullanarak veri ambarından oluşturduğumuz raporlama veritabanında satış tablosundaki acente kaynağı alanına 0-100 için direkt, 101-2000 için acente-broker ve 2001-9000 için banka kaynaklı yazabiliriz. (update satışlar set acente_kanali= case when ..........) bu sayede kullanıcılar numaraların anlamına bilmese bile satış kanalı bazında raporlama yapabilecektir. kısacası operasyonel veritabanları raporlama yapmaya uygun değillerdir ve şirket içinde standartlaşmaya izin vermezler ve karışıklığa sebep olabilirler.  Raporlama veritabanlarından alınan bilgi her departman için aynı olacaktır. bu da şirket içinde belli bir standardizasyon sağlayacaktır. Yarın Veri ambalarının sistem kaynakları açısından faydalarını yazıyor olacağım

SSRS'de data Yönetimi

SSRS kısaca sql oluşturarak burdan bir data set elde etmemizi , bu dataset ile design yapıp bu design'da rapor deploy etmemize yarar. Aslında burada benim en önemli gördüğüm nokta değişiklik yönetimidir. Bir raporla ilgili değişiklik talebi gelebilir. Bu değişiklik yeni bir alan ya da varolan alanlara yeni bir kriter şeklinde gelebilir. Bu değişikliği dataset üzerinde sql'i değiştirerek yapmak gerçekten zorlu olabilir. Sorgunun yönetilebilir olması çok önemlidir. Bu durumda SSRS bize sql yazmadan dataset üzerindeki kayıtlarla yeni bir alan yaratmamıza olanak sağlıyor, Design kısmında dataset üzerinde sağ tıklayarak "Add" seçeneğini tıklıyoruz. yeni alanın adını belirleyip mevcut alanlar üzerinden + - gibi matematiksel işlemler, mantıksal işlemler yaparak yeni alanımızı yaratıyoruz, Bu alanı da Raporumuzun üzerinde kullanabiliyoruz. Bu şekilde sql'e müdahale etmeden yeni alanlara kavuşuyor ve değişikliklikleri daha kolay yönetebiliyoruz.

SSIS'de Hatalı Veri Ayıklamak

Sql server'dan yine bir sql server'a kayıt atarken bir seferinde "insert into dbo.x select * from dbo.y " sql'ini kullanmıştım, kaynak veritabanında veri tiplerinin hepsi varchar(max)'tı. Hedef veritabanında ise decimal, varchar ve datetime bulunmaktaydı. tabiki bu sorgu bu gibi durumlarda çoğu zaman hata verecektir çünkü veritiplerin uyumsuzluğu ortaya çıkacaktır. heleki kaynak tabloda milyonlarca kayıt varsa hata olasılığı yüksektir. bu gibi durumlarda hatayı satır satır bulmaktansa SSIS bize yardımcı olur. Control flow eklentilerinden data conversion'ı inceleyin, datayı convert ettiğiniz halde bile decimal alanlara karakter girilmiş olabilir. bu gibi durumlarda SSIS'in hata ayıklama özelliğini kullanın, data conversion içinde her bir kolon için error output seçeneğinde "redirect row"u seçerseniz veritiplerinden kaynaklanan uyumsuz kayıtları SSIS istediğiniz bir yere kayıt edecek ve bu sırada veri aktarımına da ara vermeyecektir.