It seems that I will not be able to attend many sessions this year. Too many things to do behind the scenes (The "Ask the Exports" booth is busier then expected - which is good, off course). Anyway, I attend what I can - and what is important for my job :-).
I have been writing about SQL Reporting Services quite often (from previous conferences and MSDN evenings), but couldn't resist to attend an interactive session about it. With interactive discussions, we never know where we'll end up, so it can become very interesting - or noth interesting at the least .
Actually the whole title of this session is: SQL Reporting Services and Microsoft Dynamics NAV - Approaches, Tips and Tricks for Turning Microsoft Dynamis NAV Data into Information.
Typically on interactive discussions is that it's very difficult to take notes. Furthermore, I always write my blogs like this "on site" - or better - during the session. Here it goes:
One of the problems of accessing data externally is that the actual descriptions of option fields is not available through SQL Server. This is going to remain an issue. A way to avoid this, is to create an extra table that contains the descriptions of the option fields.
Furthermore, there were some concerns about SP1. It seemed that some people queried the SIFT tables (which i would not do unless absolutely necessary ). In SP1, you'll have to redesign that report to query the indexed views .
To schedule reports to be sent by email is something that cannot be done through default NAV (unless you do quite some development). In SQL Server Reporting Services this is possible out-of-the-box.
Doing a runtime upgrade (executable upgrade) will give you the opportunity to use Reporting Services on SQL Server 2005. You don't have to upgrade your functionality to the last version.
You can setup SQL Server 2005 Reporting Services to connect to a SQL Server 2000 database. It's like connecting to another datasource. Off course, if you can, upgrade everything to the latest version, because of the possibility to use the more complex queries and other stuff that comes available.
Don't use C# with reporting services, but use VB.NET. This would be the fact because "expression based languages are better and faster". Now, I don't really get what he means, because in my opinion, it's all about the framework. But I'm not an expert, so if anyone can elaborate on this ?
Scott (didn't get his last name - is it Frapier??) recommends to use Stored Procedures. SP's get compiled and cached, which is a good thing for performance. This in combination with the Reporting Services is a win-win.
Another concern, when moving from live to test - there are a few problems. Some companies like to rename their company - which renames all the tables in the database. The reports that were written don't work anymore, off course. Actually, the problem is then (in my opinion) - how do I mark my test-environment as being a test environment. Well, I have a solution for that the does not involve renaming companies or whatever. I will be blogging it in the near future .
Do we still need JetReports? Heh. Scott replied correctly: it's two different worlds. RS is much more complex to set up, but more powerful. JR is easier, but can go up to one certain level where RS can easily rise above.
Reporting Services lets you drill down on data, executing other reports. That is off course very powerful. This way, the report becomes "interactive".
Is there a training or e-learning center? Scott thinks there is, but he recommends a book - where he forgot the title of . It says: SQL Server Reporting Services 2005 - programmer to programmer. Good luck finding it .
"Reporg Builder" is designed for people that are not familiar with programming languages. It's the end user tool to build reports. As partner of developer, we would not use this - we would be using the Report Designer.
That's all. I have to hurry for my expo-duty now. Please, mark that I only noted down a few topics that were discussed. Some i missed, others were not interesting enough .
Hope you liked it.
Yeah, well, me being here alone has something to do with it :).