Login
Register
Search
Home
Forums
Jobs
LawsonGuru
LawsonGuru Letter
LawsonGuru Blog
Worthwhile Reading
Infor Lawson News Feed
Store
Store FAQs
About
Forums
Performance Management
Lawson Business Intelligence/Reporting/Crystal
OLEDB issue/number of reports
Home
Forums
Jobs
LawsonGuru
LawsonGuru Letter
LawsonGuru Blog
Worthwhile Reading
Infor Lawson News Feed
Store
Store FAQs
About
Who's On?
Membership:
Latest:
TomV
Past 24 Hours:
1
Prev. 24 Hours:
2
Overall:
5186
People Online:
Visitors:
268
Members:
0
Total:
268
Online Now:
New Topics
Lawson Landmark
LPL INSTR Functions
4/5/2024 8:32 PM
I'm writing a simple report using the Create R
Infor SCM
Translating 856 to get the ~ REF^CN^ field
4/3/2024 8:24 PM
We are trying to get the tracking number which is
IPA/ProcessFlow
Sample XML file create Flow
4/3/2024 3:43 PM
Hello everyone, I am new to creating XML files
Lawson S3 HR/Payroll/Benefits
bn105 error message
3/26/2024 6:40 PM
I need to change some of the set ups in our Life I
IPA/ProcessFlow
IPA executing Job
3/13/2024 7:08 PM
New to the IPA world and was wondering, can an IPA
Lawson S3 HR/Payroll/Benefits
Life Age Reduction on benefits plans
3/12/2024 7:15 PM
For our optional life we have an age based coverag
Lawson S3 HR/Payroll/Benefits
BN53.1 Add-In
3/7/2024 3:31 PM
We are migrating to Solstice. They require a
Lawson Business Intelligence/Reporting/Crystal
Domain Name Change
3/5/2024 7:45 PM
Our domain name needs to change and was hoping I c
S3 Customization/Development
Cobol calling Shell Script
2/29/2024 1:27 PM
Has anyone created or modified a Lawson Cobol prog
Infor ION
ION vs IPA
2/29/2024 1:24 AM
We had a person new to Lawson and Infor go to Info
Top Forum Posters
Name
Points
Greg Moeller
4184
David Williams
3349
JonA
3288
Kat V
2984
Woozy
1973
Jimmy Chiu
1883
Kwane McNeal
1437
Ragu Raghavan
1348
Roger French
1311
mark.cook
1244
Forums
Unanswered
Active Topics
Most Liked
Most Replies
Search Forums
Search
Advanced Search
Topics
Posts
Prev
Next
Forums
Lawson Business Intelligence/Reporting/Crystal
OLEDB issue/number of reports
Sort:
Oldest First
Most Recent First
You are not authorized to post a reply.
Author
Messages
Phil Simon
Veteran Member
Posts: 135
11/15/2007 10:32 PM
Lawson has told one of my clients that you can't deploy and run 100 or so Crystal Reports written via OLEDB throughout an organization and that all reports should be rewritten via ODBC. Has anyone heard of this? All prompts (dynamic and static) don't work and Lawson claims that OLEDB is not meant to be used for such a large number of reports. Obviously, this is nowhere in the support site documentation.
Thoughts?
Thanks.
John Henley
Senior Member
Posts: 3348
11/15/2007 11:31 PM
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.
hrasmuss
Basic Member
Posts: 8
12/7/2007 5:49 PM
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.
John Henley
Senior Member
Posts: 3348
12/7/2007 9:27 PM
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.
Chris Martin
Veteran Member
Posts: 277
12/7/2007 9:59 PM
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.
You are not authorized to post a reply.