Dear Nat34,
Are the user's accessing Crystal directly or through an interface. What is your db?
For example I do consulting on MagicTSD (thin-client help desk software), all users must be members of a group(s) and login with a username and a group (stored in session).
When a table is created a Group View is created for each group and is based upon the base view of the table. The group views are used to define table and field level permissions in the group views.
Reports are written against base views, but when a report is run through the app, the select of the sql is changed from the base view name to the group view - if you don't have permissions the data isn't returned. The report doesn't error - you just don't get data for that table and/or field.
This is obviously a lotta programming to implement, but the concept may work for you if you at least store the users name and position in the database. You could base the report on a stored procedure that uses the username and to find/check their position and modify the select statement based upon position.
Another solution, which would require constant maintenance, so imo is not worth the effort, is to do this with formulas using:
//Begin @ismgr
shared stringvar USR;
usr:=
Select {%User} //assumes sql expression for db return user!
case BobC : "Manager"
Case MaryY: "Not Manager"
....
Default: "Unknown"
Place this formula in the report header and then on the fields that must be suppressed from non managers, use the
shared variable as in a suppression formula on the field:
//Begin @mgrtst
shared stringvar usr;
usr <> "Manager"
The above was all concept, I haven't tested...but it should work.
Hope that wasn't too long-winded and actually helped,
ro Rosemary Lieberman
rosemary@microflo.com,
Microflo provides expert consulting on MagicTSD and Crystal Reports.