I just compared our production Run Command for Crystal ReportType to ReportType.arx from the 7.5 install directory. The only difference is we have "Crystal10URL=$CRTLOC$/*arsys*/$RPTLOC$..." in a few places rather than "Crystal10URL=$CRTLOC$/*arreports*/$RPTLOC$...." I am figuring if that was incorrect we would have bigger issues.
Jason On Thu, Sep 17, 2009 at 10:39 AM, Jason Miller <[email protected]>wrote: > Thanks Rod! > > I added the userid to the report and removed the credentials from the > System DSN and was prompted for credentials. It looks like it ignores what > credentials are in the report (as expected). > > I ran a tail on the aruser.log while clicking the report button. The login > and logout events don't make too much sense to me. The first thing that is > done is the user specified in the System DSN logs out (when did it log > in?). Then the MidTier Service logs in, the test user logs in, the MidTier > Service logs out, the test user logs out and the System DSN user logs in > (which makes sense in the creds are stored). > > <USER> <TID: 0000002596> <RPC ID: 0013381695> <Queue: Fast > > <Client-RPC: 390620 > <USER: SystemDSNuser > > /* Thu Sep 17 2009 10:07:58.8480 */ LOGOUT SystemDSNuser > > <USER> <TID: 0000002756> <RPC ID: 0013381696> <Queue: Fast > > <Client-RPC: 390620 > <USER: MidTier Service > > /* Thu Sep 17 2009 10:07:58.8730 */ LOGIN MidTier > Service > > <USER> <TID: 0000003664> <RPC ID: 0013381700> <Queue: List > > <Client-RPC: 390620 > <USER: LimitedTestUser > > /* Thu Sep 17 2009 10:07:58.9230 */ LOGIN > LimitedTestUser > > <USER> <TID: 0000000616> <RPC ID: 0013381701> <Queue: Fast > > <Client-RPC: 390620 > <USER: MidTier Service > > /* Thu Sep 17 2009 10:07:58.9380 */ LOGOUT MidTier > Service > > <USER> <TID: 0000003620> <RPC ID: 0013381727> <Queue: Fast > > <Client-RPC: 390620 > <USER: LimitedTestUser > > /* Thu Sep 17 2009 10:08:00.1670 */ LOGOUT > LimitedTestUser > > <USER> <TID: 0000002596> <RPC ID: 0013381754> <Queue: Fast > > <Client-RPC: 390620 > <USER: SystemDSNuser > > /* Thu Sep 17 2009 10:08:01.3900 */ LOGIN SystemDSNuser > > I understand why the System DSN user would login since the ODBC connection > has the credentials but why is the test user logged out? It is not a full > logout because the test user can still use the form without reauthenticating > after closing the report window. I do not see a login event for the test > user after the logout but the session is still active. > > Is this a bug? Might be time to report it? > > Jason > > > On Thu, Sep 17, 2009 at 2:00 AM, Rod Harris <[email protected]> wrote: > >> Hi Jason, >> >> I'm a bit like you and I do have a variety of different versions of >> ARS and the mid-tier. I have a Win 2003 7.5 dev server and 3 x 7.1 >> servers, 2 prod 1 dev all with matching mid-tier versions. I'm using >> one BOXI server for all my ARS servers. I have dedicated different >> system DSNs to each ARS server on the BOXI server. Some of these I >> have set up with usernames in the DSN and it does use them when >> specified. >> >> My production DSN includes just the server name and it seems to take >> the username of the logged in user in this instance. I have seen the >> problem you describe where it asks for the login name before though. >> Looking at my reports I do have a userid in the report itself. Maybe >> you need to do this, rather than leave it blank. >> >> If I get a chance tomorrow I will have a closer look at my setup to >> try and isolate your issue. >> >> Rod >> >> >> >> On 17/09/2009, Jason Miller <[email protected]> wrote: >> > ** Hi Rod, >> > >> > Yes the username/password are configured in the System DSN on the CR >> server. >> > This is the first time we have tried to limit the results with >> permissions >> > that are less than APP-Support, which the System DSN user is a member of >> as >> > well as most of our users. I had never noticed that it is using the >> > credentials stored in the System DSN to authenticate. Probably because >> > queries based on $USER$ and $GROUPS$ work as expected for the user >> > authenticated to the MT. >> > >> > I Removed the Credentials from the System DSN and now the report prompts >> for >> > credentials. After supplying credentials the records returned are only >> the >> > ones the user should see. The problem now is the user should not be >> > prompted for their credentials when running the report. >> > >> > I had not read what the newer versions said about setting up CR so I did >> a >> > refresher. I found this on page 117 of the 7.5 Mid-Tier guide. >> > >> > Crystal Designer and Crystal Reports use the user name and password in >> the >> > System DSN to log in to AR System. When you create reports in Crystal >> > Designer, you use a System DSN complete with a user name and a password. >> If >> > Crystal Designer requests user information, do not provide it. The >> > information in the System DSN should be sufficient. If not, provide the >> > required information in the System DSN, not in Crystal Designer. Do not >> use >> > a User DSN when you create or run Crystal Reports. Before you run any >> > reports, however, modify your System DSN to remove the user name and >> > password. This causes Crystal Reports to use the user name and password >> of >> > the user currently logged in. Failure to remove the user name and >> password >> > from the System DSN might give you unexpected results when you run your >> > report. >> > >> > As far as I can tell I am now setting up the report (reattached to the >> > report form) and System DSN correctly. The report should use the >> > credentials of the user logged into MT and not prompt. >> > >> > This db has been upgraded from 7.0 -> 7.0.1 -> 7.5 over the years. I >> > remember having issues with the Report Type records not being updated >> during >> > upgrade from 6.x to 7.x because the records already existed. I had to >> > manually chance some of the Command values. Maybe one of the Command >> fields >> > needs to be updated? >> > >> > This is a MT 7.1 running against ARS 7.5 which is kind of backwards. >> Maybe >> > there is an issue here. We are still building our 7.5 MT servers (there >> has >> > been no rush). Maybe I'll have to finish up the Crystal integration on >> our >> > pre-production 7.5 MT and try it again. >> > >> > Jason >> > >> > >> > On Wed, Sep 16, 2009 at 6:07 PM, Rod Harris <[email protected]> wrote: >> > > >> > > Just a possibility. >> > > >> > > Do you have a user name and password configured for the ODBC data >> > > source on the crystal web server? >> > > >> > > Rod >> > > >> > > On 17/09/2009, Jason Miller <[email protected]> wrote: >> > > > ** As I mentioned in the “Printing/Crystal Reports error....” >> thread, we >> > are >> > > >> > > >> > > >> > > > seeing that row level permission are not enforced when triggering a >> > Crystal >> > > > Report from an Active Link on the Mid-Tier. Open the same form and >> > press >> > > > the same button with the same user in the WUT and only the records >> that >> > the >> > > > user has permissions to are shown in the report. >> > > > >> > > > Has anybody else experienced this? >> > > > >> > > > ARS 7.5 p1 >> > > > Mid-Tier 7.1 p5 (win 2003/Apache 2.2/Tomcat 5.5.26) >> > > > WUT 7.5 p2 / WUT 7.1 p2 >> > > > Crystal Reports Server 11.5 >> > > > MS SQL 2005 (Windows 2008 x64 both db and app servers) >> > > > >> > > > Thanks, >> > > > Jason >> > > > _Platinum Sponsor: [email protected] ARSlist: "Where the >> Answers >> > > > Are"_ >> > > >> > > >> > >> _______________________________________________________________________________ >> > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> > > Platinum >> > > Sponsor:[email protected]<sponsor%[email protected]>ARSlist: >> > > "Where >> > the Answers Are" >> > > >> > >> > _Platinum Sponsor: [email protected] ARSlist: "Where the Answers >> > Are"_ >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> Platinum >> Sponsor:[email protected]<sponsor%[email protected]>ARSlist: >> "Where the Answers Are" >> > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
