View Full Version: Crystal Report With Data Refresh - Passing User Id

LawsonTalk > Reporting (NEW!!) > Crystal Report With Data Refresh - Passing User Id


Title: Crystal Report With Data Refresh - Passing User Id


georgegraham - September 18, 2006 03:39 PM (GMT)
Is there a way when you publish a Crystal Report in ERS that runs with data refresh to pass the user id and password of the users logged into ERS so that it does not have to prompt them for it?

cjmart - September 18, 2006 04:19 PM (GMT)
Are you referring to Enteprise Reporting or Reporting Services? If it's Reporting Serivces, what version are you on?

Are you just wanting to eliminate the need of the end user to provide a db user/password at runtime, or are you wanting to filter the data based on the end user running the report?

georgegraham - September 18, 2006 07:27 PM (GMT)
This is Reporting Services. I want the first - to eliminate the runtime prompting of the db user/password - since they have already provided this when they logged into portal...

I'm filtering (on some reports) by way of the security classes - not through the report itself.

cjmart - September 18, 2006 07:31 PM (GMT)
What version of Reporting Services? Sounds like your reports are using the Lawson OLE DB connector as the data source - is this correct?

georgegraham - September 18, 2006 07:55 PM (GMT)
Yes - OLEDB 9 and RS 1.3 with latest patches.

cjmart - September 19, 2006 02:47 PM (GMT)
Upgrading to Reporting Services (RS) 9 would give you this with the Bursting functionality.

The one caveat is that in addition to maintaining laua application security, you will also have to maintain report/data level security rules within RS. You can't leverage laua security for this, unless you wanted to do a custom export from laua and import into RS.

georgegraham - September 19, 2006 03:25 PM (GMT)
OK - 2 questions:

Does RS 9 work with IOS 8.0.3? Or does the environment need to be upgraded to 9 as well?

I would understand about not leveraging laua for access to the reports/etc..but my assumption is that since we would be using OLEDB it would still leverage laua from a data access standpoint,which is how some of the data filtering is done...



Hosted for free by InvisionFree