LRS / LBI vs. Microsoft REporting Services

the big one off the top of my head is LBI's ability to drill down to transaction level detail.

LBI is basically Business Objects/Crystal, so you could expand you question to anyone that has used MRS and Crystal.

Joseph, what a great question! I wrote about MS SQL Reporting Services a few years ago (https://www.danalytics.co...rchive/2004-06.htm), but perhaps it's time for an updated side-by-side comparison.

LBI - Advantages / MSSQL RS - Disadvantages

- LBI is an umbrella product set, and includes a number of other products beyond Reporting Services, e.g., Dashboards/Scorecards, Smart Notiifications.

- This may not be true anymore (I need to get a new copy installed) but the MSSQL report designer, while look/feel similar to Microsoft Access, is hosted in Visual Studio much more difficult to use than Crystal. Crystal's designer just "feels" easier to use.

- LBI supports "bursting" of standard Lawson reports (i.e. GL290) into separate pieces of content.

- LBI 9.0 supports single-sign on.

- If you use Lawson OLEDB, the Query Builder is integrated into Crystal. If you use MSSQL RS, you have to figure out the DME syntax and past it into the report query. Not a big deal.


MSSQL RS - Advantages / LBI Disadvantages

- The HUGE advantage of MSSQL RS is COST. It's essentially free, whereas LBI (or Business Objects) = $$.

- Since it's a .NET application, you have the whole .NET framework at your disposal, and can embedded .NET code into the report.

Where I think they're about even:

- Database support. MSSQL RS is not just for SQL Server--it can report off of any OLEDB/ODBC data source. As can Crystal/LBI.

- Report management / scheduling / delivery.

In my mind, two of the "advantages" noted by Lawson are really a wash, as they can be implemented pretty easily in either product:

1. Security. Lawson touts the OLEDB provider, but when the "rubber meets the road" most clients end up writing their reports using native/ODBC providers to eliminate speed issues associated with Lawson OLEDB provider. What I always recommend as a "best practice" is a two-pronged approach: 1) implement the parameter selection via Lawson OLEDB (so that user can only select the records they have access to via Lawson security), and 2) implement the report itself via native database provider using parameters selected. It's the best of both worlds. And can be implemented with LBI as well as MSSQL RS.

2. Drill-Around. It's pretty easy to add it in MSSQL RS (it's really just a matter of a dynamic URL).