Users access to RDA

It is my impression that giving RDA access to "users" is generally not done. Reasons include difficult tool for users, update capability in the hands of people who should not have it, report duplication, remote development difficulties, etc.

I just wanted to get a general confirmation that most OW shops to not have many "users" out there writing their own reports.

That true?

AS400 V5R1, XE+XU1+45ESUs, SP16, NT-SQL7 for CO

Jack :

Even in large shops, it's difficult to find places where more than
15 users access to JDE development tools.

Sebastian

Jack,

Yes, I'll confirm your impression that RDA is not a user-friendly tool, and that there are serious security risks in giving access to this application to end-users.

We've instead created views in our Oracle database that our end-users can access through Crystal Reports. In this way, we have control over which tables and columns different users/groups have access to.

I'm not trying to sell Crystal Reports, but it is orders of magnitude easier to use this tool than RDA for most needs. The only place that RDA shines is if you need to do complex coding as part of your report.

Don Sauve
Wagstaff, Inc.
OW XE, Update 1, SP15.1, HP-UX 11.0, Oracle 8.1.6

Yes, we have a significant number of users writing adhoc reports in our production environment.

We facilitate this by creating for them a <user>-R logon. This -R logon has access to RDA but the backend Oracle user attached to the logon has read-only access to the database.

Dave.

David D. Helsley, Inc.
[email protected]
Xe, HPUX, Sp17.1, Oracle, TSE, Web
Xe, W2K, Sp17.1, MSSql, TSE

Dave,

You realize you leave the door open to trojan horses with that approach ...

Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials

Not as much as you'd think. I neglected to mention that the -R accounts can
only create versions starting with "R" and that row security prevents all
other users from seeing versions starting with "R". We've also secured -R
accounts from certain business functions that could be used to write and
launch scripts on the server.

The -R account can only create versions not templates.

It will never be bulletproof, but, do you see any other gapping holes?

Dave.

David D. Helsley, Inc.
(317)879-4483 [email protected] (Client site.)
(859)466-6746 [email protected]

I find that RDA is too complex for most users. Plus if a 'big-wig' wants a
report we don't want them wasting time trying to figure out RDA. We have a
report writer who just writes reports in JDE and Crystal for different
systems. RDA is also pretty dangerous unless users are given read only
access to the database.

Colin

B733.2 SP17.1_F1
Intel/NT/Oracle 8.1.7.1

Dave,

I'm not in the thinking mood so could you give a summary of how you did
this? Did you use security on the F983051? How did you secure the BSFN's?

Thanks

Colin

B733.2 SP17.1_F1
Intel/NT/Oracle 8.1.7.1

Re: RE: Users access to RDA

When you say "read only" access to DB... how do you do this within OW? How do you keep them from using table I/O? Some fantastic entries in OW security for every file?

Sounds like David H. has an interesting approach.

Seems we have more and more reports using workfiles (sometimes this can really help with performance on massive files - depending)... so that presents a bit of a problem. But we can leave those to the "developers"...

AS400 V5R1, XE+XU1+45ESUs, SP16, NT-SQL7 for CO

Re: RE: Users access to RDA

Colin,

Read only was the easy part just create an Oracle user with read-only access to the business data and attach it to the user.

Yes, row security was created for the F983051.

The BSFNs, unfortunatly, required a small mod. Could not find anything in OneWorld to secure them.



Dave.

David D. Helsley, Inc.
[email protected]
Xe, HPUX, Sp17.1, Oracle, TSE, Web
Xe, W2K, Sp17.1, MSSql, TSE

Re: RE: Users access to RDA

Dave,

so these "R" versions are only run by the -R accounts? That should take care of direct DB I-O. How about UBE Interconnects? Are those locked out also?

Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials

Re: RE: Users access to RDA

Larry,

Did not test it. But, I assumed that the version of the called UBE would have to be an R* version as well. If I get a chance I'll test this assumption later.

Have fun.

Dave.

David D. Helsley, Inc.
[email protected]
Xe, HPUX, Sp17.1, Oracle, TSE, Web
Xe, W2K, Sp17.1, MSSql, TSE

I would agree that access to RDA should not be given to every user. However, a small group of "Power Users" with a small amount of training could add a large degree of value for very little cost. I don't know how much Crystal reports costs to implement or maintain, but RDA is already paid for.


Ken

XE SP 16
Win2000/Oracle 8.1.6.

For those of you using Crystal, are you using the JDE ODA driver, or are the Crystal users connecting to the database directly, and converting the JDE Date formats (cYYDDD) and decimals in $ fields themselves?

If you're using the ODA driver, is it working fairly well?

Scott MacIntosh
Xe SP 16.1 / Upd 2
JDE CNC (Unix / Oracle / Win2k / SQL Svr)
Interop (COM / Java)

Scott,

For how we do it here please search the archives on this for keywords such as Crystal and ODA. I have posted several times on these subjects - getting rather wordy in some cases so I don't want to repeat it all again


Cheers,


Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials

Thanks Larry,

The archive search confirmed my suspicion that ODA is not that robust, and I like the sound of your approach better ( users querying database views).

Are your users running directly against your production database, or do you copy the Production data to another server periodically for Crystal users?

TIA



Scott MacIntosh
Xe SP 16.1 / Upd 2
JDE CNC (Unix / Oracle / Win2k / SQL Svr)
Interop (COM / Java)

Scott,

User queries and reports run directly off the production database. Two reasons: 1) we can't afford another database server; 2) To date even the most malformed/inefficient queries generated by users have failed to significantly impact response time (the RAID server gets pounded to death sometimes but Oracle handles the load magnificiently!). Keep in mind though that our table sizes are smaller than many (45,000 items, 1 branch, 1 million F0911 rows, ...).

Regards,

Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials