OLEDB issue/number of reports

That has to be one of the dumbest things I've heard! Well, it makes sense but you certainly don't say it like that. That's like saying, please buy our product, but don't really use it because it sucks.

As a technology, OLEDB is FASTER than ODBC. For example, MSSQL OLEDB is faster than MSSQL ODBC. The reason is because ODBC has an extra layer in it. Why Lawson saying ODBC is faster than OLEDB is because of Lawson's implementation of OLEDB, and they're comparing apples to oranges. What they should say is that "the native database's ODBC is faster than Lawson OLEDB" because of the built-in Lawson security which is applied, the "Lawson-ness" of the Query Builder (i.e. being able to reflect the dbdef relationships, etc.). And, last but not least, the fact that Lawson OLEDB passes through the web server.

I've always maintained that--for production reports developed in Crystal and deployed in Crystal Enterprise or LBI--they should ALWAYS be using the native database provider. Where Lawson OLEDB should be used is for parameter/selection and for prototyping and occasional "casual" reports.

Hi John:
We are in the midst of implementing Crystal/LBI for our organization. I was wondering if you could expand on your opinion as to why you stated the following:

"I've always maintained that--for production reports developed in Crystal and deployed in Crystal Enterprise or LBI--they should ALWAYS be using the native database provider. Where Lawson OLEDB should be used is for parameter/selection and for prototyping and occasional "casual" reports."

Our higher ups are concerned with the security and audit trail that does not seem to exist with ODBC but does for OLE DB.

If you haven't already, please read this article on the OLEDB provider: https://www.danalytics.co.../archive/2004-08.htm

Basically, it's a matter of performance and stability. By using native database providers, the report designer has much greater control over data access via SQL. Since I'm referring to frequently-used production reports (like Payroll registers, etc...think back to the old green bar days with the "production control" model). Those report "objects" should be controlled via security, but not the data that gets accessed. That's where LBI (or perhaps Crystal Enterprise) security can be used--to protect the object itself, and who can run it. If it's a departmental report, then each copy of the report object should select only those records appropriate for that department.

As for security, you are correct. Where I do think the OLEDB provider is completely appropriate is for non-production-control type reports, which are run on an occasional basis. In those cases, having Lawson provide the security is desirable. Also for publishing or bursting "Lawson Back Office" reports....

One final point. In your post you refer to "audit trail that does not seem to exist with ODBC". There isn't an audit trail either in Lawson OLEDB.

Hans,

As John indicated, controlling what data the end users can see can be handled at the application level (ie LBI, BOXI). If management concerns have to do with what report developers are able to see, one option is to control this at the database level. For example, if there are devlelopers that should not see pay info, a select number of tables (ie EMPLOYEE, PRRATEHIST, HRHISTORY, etc) can be restricted for their database user. Also, there are auditing options at the database level.