Geçtiğimiz haftalarda SSRS 2005/2008 üzerinde çalışıyorum ve bazı sunucu tarafı raporları oluşturdum. Bazı uygulamalar için, bir meslektaşım o özel durum için RDLC'ye bakmamı önerdi. Şimdi RDL ve RDLC arasındaki temel farka kafa yormaya çalışıyorum.

Bu bilgilerin aranması, en iyi ihtimalle parçalı bilgi verir. Bunu öğrendim:

• RDLC raporları, verilerin nasıl alınacağına ilişkin bilgileri depolamaz.
• RDLC raporları doğrudan ReportViewer kontrolü tarafından yürütülebilir.

Ancak yine de RDLC dosyası ile diğer ilgili sistemler (Raporlama Sunucusu, kaynak veritabanı, istemci) arasındaki ilişkiyi tam olarak anlamıyorum.

RDLC dosyaları hakkında iyi bir kavrayış elde etmek için, kullanımlarının RDL dosyalarından nasıl farklı olduğunu ve hangi durumda RDL yerine RDLC'nin seçileceğini bilmek isterim. Kaynaklara bağlantılar da açıktır.

Güncelleme:

ASP.NET forumlarındaki bir iş parçacığı aynı sorunu tartışır. Ondan konu hakkında daha iyi bir anlayış kazandım.

RDLC'nin bir özelliği , ReportViewer denetiminde tamamen istemci tarafında çalıştırılabilmesidir .

• Bu, Raporlama Servisleri örneğine olan ihtiyacı ortadan kaldırır ve hatta herhangi bir veritabanı bağlantısı ihtiyacını ortadan kaldırır, ancak:
• Raporda ihtiyaç duyulan verilerin manuel olarak sağlanması gerekliliğini ekler.

Bunun bir avantaj mı yoksa dezavantaj mı olduğu belirli uygulamaya bağlıdır.

Benim uygulamamda, Raporlama Hizmetlerinin bir örneği zaten mevcut ve raporlar için gerekli veriler bir veritabanından kolayca alınabilir. RDLC'yi düşünmem için herhangi bir neden kaldı mı, yoksa sadece RDL'ye bağlı kalmalı mıyım?

Deneyimlerime göre, her iki konu hakkında da düşünecek birkaç şey var:

I. RDL raporları genel olarak HOSTED raporlardır. Bu, SSRS Sunucusunu uygulamanız gerektiği anlamına gelir. Raporlama dili için SQL Server'dan Visual Studio'nun yerleşik bir uzantısıdır. SSRS'yi kurduğunuzda, raporlarla çalışmak onsuz çalışmaktan çok daha kolay olan 'İş Zekası Geliştirme Stüdyosu' adında bir eklentiniz olmalıdır.

R eport

D efinition

L angauge

RDL raporlarının faydaları:

1. Raporları, sizin için çalışan hizmetlerin bulunduğu bir ortamda barındırabilirsiniz.
2. Güvenliği bağımsız bir kavram olarak ele almak için bir öğe veya devralma düzeyi üzerinde güvenliği yapılandırabilirsiniz.
3. Hizmeti e-postalar gönderecek (erişiminiz olan bir SMTP sunucunuz olması koşuluyla) ve dosyaları programlara kaydedecek şekilde yapılandırabilirsiniz.
4. Genel olarak 'ReportServer' olarak adlandırılan bir veritabanınız var ve yayınlandıktan sonra raporlar hakkında bilgi sorgulayabilirsiniz.
5. Bu raporlara, ASP.NET, WPF (winform control bleh!) İle yazılmış bir istemci uygulamasındaki 'ReportViewer' veya 'ProcessingMode.Remote' kullanarak .NET'deki Winforms üzerinden erişebilirsiniz.
6. Daha fazla esneklik kazanmak için bir kullanıcının görebileceği ve kullanabileceği parametreleri ayarlayabilirsiniz.
7. Bağlantı dizeleri için kullanılmak üzere bir raporun bölümlerini 'Veri Kaynakları' olarak ve bir sql sorgusu, xml veya diğer veri kümelerini 'Veri Kümesi' olarak yapılandırabilirsiniz. Bu parçalar ve diğerleri, verileri düzenli bir şekilde önbelleğe alacak şekilde depolanabilir ve yapılandırılabilir.
8. Http: // / ReportServer / ReportingService2010 veya / ReportExecution2005 hizmetlerinin .NET proxy sınıflarını yazabilirsiniz. Ardından, SSRS verilerini doğrudan SSRS raporlarını kodda barındıran bir Sunucudan e-postayla göndermek, kaydetmek veya değiştirmek için .NET'te KENDİ yöntemlerinizi oluşturabilirsiniz. ReportService2010.asmx kullanarak SSRS raporunu sharepoint'ten programlı olarak dışa aktarın

Downsides:

1. SSRS, hızlı bir şekilde yükseltmek için diğer şeylere kıyasla biraz daha garip. Çoğu insanın, güvenlik politikası ve raporları VS'ye 'eklenti' olarak tasarlaması kafasını karıştırır. SQL 2005 = TEKLİFLERE KARŞI 2005, SQL 2008 = TEKLİFLERE KARŞI 2008, SQL 2012 = TEKLİFLERE KARŞI 2010 (LOL).
2. 1'de devam eden IMHO güvenlik ayarları politikası aptalca aşırı karmaşıktır. Hizmet için barındırılan sayfada sunucu güvenliği, veritabanı güvenliği ve roller, iki güvenlik ayarı vardır. Çoğu kişi içeri giremediğinden ve diğer kullanıcıların neden yapamadığını merak ettiğinden yalnızca bir yönetici kurar. SSRS ile ilgili en yaygın şikayet veya soru, genel olarak benim deneyimlerime dayanarak gelmekle ilgilidir.
3. Raporunuzu sözde 'geliştirecek' 'ifadeler' kullanabilirsiniz. Çoğu zaman birkaç taneden fazlasını yaparsınız ve raporunuz performansta bir taramaya gider.
4. Yapabileceğiniz ve dışa aktarabileceğiniz belirli miktarda şey var. SSRS, bir javascript hack olmadan bildiğim raporlamanın üzerine gelmiyor.
5. Aptal SSRS yapılandırması sistemi geri dönüştürdüğü için hız ve performans darbe alabilir ve ilk rapor bazen siteyi yüklerken zaman alabilir. Bunu değiştirerek bunun üstesinden gelebilirsiniz, ancak daha iyi çalıştığı için bir canlı tutma hizmeti yapmayı buldum.

II. RDLC raporları, HERHANGİ BİR YERDE BARINDIRILMAYAN İSTEMCİ İÇEREN raporlardır. İsimdeki fazladan c 'Müşteri' anlamına gelir. Genellikle bu, yalnızca Visual Studio İstemci Uygulamalarında kullanılmak üzere tasarlanmış RDL dilinin bir uzantısıdır. Bir 'raporlama' öğesi eklediğinizde Visual Studio'da bulunur.

RDLC raporlarının faydaları:

1. Bir wcf servisini veri setine çok daha kolay bağlayabilirsiniz.
2. Veri kümesi üzerinde daha fazla kontrole sahip olursunuz ve Entity çerçeve nesneleri veya ADO.NET ile doldurulmuş POCO sınıflarını ve tabloların kendisini kullanabilirsiniz. Rapora bağlamadan önce verileri optimizasyon için kullanabilirsiniz.
3. Görünümü doğrudan kodun arkasındaki eklentilerle daha fazla özelleştirebilirsiniz.

Downsides:

1. Parametreleri kendi başınıza halletmeniz gerekir ve bacak çalışmasına yardımcı olmak için sarmalayıcı yöntemleri uygularken beklenenden biraz daha fazla ve talihsizdir.
2. Kullanıcı, uzak modda olmadıkça ve bir RLD raporuna erişmedikçe bir 'ReportViewer' denetimindeki parametreleri GÖREMEZ. Bu nedenle, ona geçmek için kontrolün dışında kendi başınıza metin kutuları, açılır menüler, radyo düğmeleri yapmanız gerekir. Bu gibi bazı insanlar kontrol ekledi, şahsen ben değilim.
3. Dağıtım için raporlara hizmet verirken yapmak istediğiniz her şeyi kendiniz oluşturmanız gerekir. E-posta gönderme, abonelikler, kaydetme. Üzgünüz, bunu .NET'te derlemeniz gerekiyor veya bunu zaten yukarıdan yapan bir proxy uygulamanız gerekiyor, sadece barındırılan raporları kullanıyor olabilirsiniz.

Açıkçası her ikisini de farklı amaçlar için seviyorum. Analistlere her zaman kullandıkları ve grafikler, çizelgeler, detaya inmeler ve Excel'e aktarım için ince ayarlar yapmasını istersem, RDL kullanıyorum ve SSRS'nin sitesi e-posta dağıtımlarını yönetmenin tüm ayak işlerini yapmasını sağlıyor. Rapor bölümü olan bir uygulama istiyorsam ve uygulamanın kuralları ve yönetişimi olan kendi modülü olduğunu biliyorsam bir RDLC kullanıyorum ve parametrelerin daha küçük olması ve kullanıcının rapor kısmına gelmeden önce aldığı kararlar tarafından yönlendirilmem müşteri ve sitede bulunurlar ve genellikle sadece bir zaman dilimi veya tür seçerler ve başka bir şey seçmezler. Genel olarak karmaşık bir rapor RDL'yi kullanırdım ve basit bir şey için RDLC IMHO'yu kullanırdım.

Umarım bu yardımcı olur.

S: RDL ve RDLC formatları arasındaki fark nedir?

A: RDL dosyaları, Rapor Tasarımcısının SQL Server 2005 sürümü tarafından oluşturulur. RDLC dosyaları, Rapor Tasarımcısının Visual Studio 2008 sürümü tarafından oluşturulur.

RDL ve RDLC formatları aynı XML şemasına sahiptir. Bununla birlikte, RDLC dosyalarında, bazı değerlerin (sorgu metni gibi) boş olmasına izin verilir; bu, bir Rapor Sunucusunda yayınlanmaya hemen hazır olmadıkları anlamına gelir. Eksik değerler RDLC dosyası Rapor Tasarımcısının SQL Server 2005 sürümü kullanılarak açılarak girilebilir. (Önce .rdlc'yi .rdl olarak yeniden adlandırmanız gerekir.)

RDL dosyaları, ReportViewer kontrol çalışma zamanıyla tamamen uyumludur. Ancak, RDL dosyaları, otomatik olarak veri bağlama kodu oluşturmak için ReportViewer denetiminin tasarım zamanına bağlı olan bazı bilgileri içermez. Verileri manuel olarak bağlayarak, RDL dosyaları ReportViewer denetiminde kullanılabilir. Yeni! RDL Viewer örnek programına da bakın.

ReportViewer denetiminin veritabanlarına bağlanmak veya sorguları yürütmek için herhangi bir mantık içermediğini unutmayın. Böyle bir mantığı ayırarak ReportViewer, veritabanı olmayan veri kaynakları dahil tüm veri kaynaklarıyla uyumlu hale getirildi. Ancak bu, ReportViewer denetimi tarafından bir RDL dosyası kullanıldığında, RDL dosyasındaki SQL ile ilgili bilgilerin denetim tarafından yok sayıldığı anlamına gelir. Veritabanlarına bağlanmak, sorguları yürütmek ve ReportViewer denetimine ADO.NET Veri Tabloları biçiminde veri sağlamak ana bilgisayar uygulamasının sorumluluğundadır.

http://www.gotreportviewer.com/

RDL ve RDLC arasındaki farkın, RDL'nin SQL Server Raporlama Servisleri için kullanılması ve RDLC'nin istemci tarafı raporlama için Visual Studio'da kullanılması olduğunu hep düşünmüşümdür. Uygulama ve düzenleyici neredeyse aynıdır. RDL açılımı Report Defintion Languageve RDLC Report Definition Language Client-side .

Umarım bu yardımcı olur.

Tecrübelerime göre, büyük raporlarda yüksek performansa ihtiyacınız varsa (bu biraz müşteri özelliklerine bağlıdır), rdlc ile gidin. Ek olarak, rdlc raporları size verileriniz üzerinde tam bir kontrol sağlar, müşteri tarafı raporları kullanarak boşa giden veritabanı gezilerinden vb. Kurtulabilirsiniz. Şu anda üzerinde çalıştığım projede, kritik bir raporun sunucu tarafında işlenmesi yaklaşık 2 dakika gerektirir ve o süre için hangi raporlama sunucusuna ulaşırsa onu hemen hemen çıkarır. İstemci tarafı görüntülemeye geçerek, rapor sunucusunda yük olmadan ve yalnızca veri kümeleri indirildiği için daha az bant genişliği kullanılarak 20-40 saniyeye çok daha yakın bir performans görüyoruz.

Kilometreniz değişebilir ve özellikle raporunuz bir sunucu tarafı raporu olarak tasarlandığında rdlc'nin ek geliştirme ve bakım karmaşıklığını buluyorum.

Bu noktalardan bazıları yukarıda ele alınmıştır, ancak işte VS2008 ortamı için benim 2 sentim.

RDL (Uzaktan raporlar): Çok daha iyi geliştirme deneyimi, zamanlama, anlık raporlama gibi bazı gelişmiş özellikleri kullanmanız gerekiyorsa daha fazla esneklik ...

RDLC (Yerel raporlar): Rapora göndermeden önce veriler üzerinde daha iyi kontrol (verileri rapora göndermeden önce doğrulamak veya değiştirmek daha kolaydır). Çok daha kolay kurulum, Raporlama Servislerinin bir örneğine gerek yok.

Yerel raporlarla ilgili BÜYÜK bir uyarı, müşterileriniz çok sayıda büyük rapor çalıştıracaksa performansı ciddi şekilde etkileyebilecek bilinen bir bellek sızıntısıdır. Bunun, rapor görüntüleyicinin yeni VS2010 sürümüyle ele alınması gerekiyor.

Benim durumumda, Raporlama Servislerinin bir örneğine sahip olduğumuz için, RDL'ler olarak yeni raporlar geliştiriyorum ve sonra bunları yerel raporlara dönüştürüyorum (ki bu kolay) ve bunları yerel raporlar olarak dağıtıyorum.

Kullanabileceğiniz bir raporlama hizmetleri altyapınız varsa, onu kullanın. RDL geliştirmenin biraz daha hoş olduğunu göreceksiniz. Raporu önizleyebilir, parametreleri kolayca vb. Ayarlayabilirsiniz.

Ben ise şu anda daha esnek ve daha kolay yönetilebilir görünüyor çünkü RDL düşkündürler, RDLC sizin lisans basitleştirmek görünüyor ki bir avantaja sahiptir. RDLC'nin bir Raporlama Hizmetleri örneğine ihtiyacı olmadığından, onu kullanmak için Raporlama Hizmetleri Lisansına ihtiyacınız olmayacaktır.

Bunun SQL Server'ın daha yeni sürümleri için hala geçerli olup olmadığından emin değilim, ancak bir seferde SQL Server Veritabanı ve Raporlama Hizmetleri örneklerini iki ayrı makineye koymayı seçerseniz, iki ayrı SQL Server lisansına sahip olmanız gerekirdi:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

Raporlama Hizmetleri lisansı ile ilgili diğer benzer bloglar ve gönderiler için Bing yapabilirsiniz .

VS2008 için, RDL'nin size RDLC'den daha iyi düzenleme özellikleri sağladığına inanıyorum. Örneğin, RDL ile bir metin kutusundaki seçili bir metin miktarındaki Kalın'ı değiştirebilirim, ancak RDLC'de bu mümkün değildir.

RDL: abcd efgh ijklmnop

RDLC: abcd efgh ijklmnop -veya- abcd efgh ijklmnop (tek seçenekleriniz)

Bunun nedeni, RDLC'nin 2005'ten önceki bir ad alanı / biçimlendirme kullanması ve RDL'nin 2008 kullanmasıdır. Ancak bu, VS2010 ile değişecektir.

Daha az karmaşık olan ve asp.net web sayfaları tarafından tüketilen daha az sayıda raporumuz varsa. Rdlc ile gitmek daha iyidir, çünkü RS örneğiyle ilgili raporları korumaktan kaçınabiliriz. ancak veriyi DB'den elle alıp rdlc'ye bağlamalıyız.

Eksileri: görsel stüdyoda rdlc tasarlamak, SSrs tasarımcısına kıyasla biraz zor.

Pro: Bakım kolaydır. Rapor sayfamızdan dışa aktarılırken, sunucu tarafı raporlarına göre performans artışı gözlemlendi.

asp.net'te raporu kullanmak istiyorsanız, rapor oluşturucu / rapor sunucusunda kullanmak / görüntülemek istiyorsanız .rdl kullanın ve sadece biçimi manuel olarak dönüştürerek .rdlc kullanın