Hide parameter for some users

I'm trying to decide whether I can use sql reports for my application, and
the main problem I've run into thus far is that my available parameters need
to change based on the user who is running the report. For instance,
low-level users should only be able to see data about themselves, whereas
managers should be able to select from a drop-down list of all users. Is
there any way to set the user prompt/visibility for a parameter based on the
role of the person running the report?The easiest way I can think of to manage this is to have two versions of the
same report. With the regular version, pass =User!UserID into the query
parameter. In the manager's version, populate the same parameter from a
drop-down list. Then set different permissions when you deploy the reports.
If you need to do it in a single report, you might be able to write some
custom code to pass in flags to the query and work out the difference
between managers and employees in your data source query.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"jgephart" <jgephart@.discussions.microsoft.com> wrote in message
news:36979870-6D83-4C49-B1E6-88D8CBC51678@.microsoft.com...
> I'm trying to decide whether I can use sql reports for my application, and
> the main problem I've run into thus far is that my available parameters
> need
> to change based on the user who is running the report. For instance,
> low-level users should only be able to see data about themselves, whereas
> managers should be able to select from a drop-down list of all users. Is
> there any way to set the user prompt/visibility for a parameter based on
> the
> role of the person running the report?|||Thanks, Jeff. This will affect a whole series of reports, so I don't really
want to maintain separate versions. I think I'm going to be able to go with
passing in User!UserID to the query that builds the drop-down list of users.
I can't hide the drop-down list, but at least I can make sure it's only
populated with a single user if that user doesn't have permission to see
other people's data.
"Jeff A. Stucker" wrote:
> The easiest way I can think of to manage this is to have two versions of the
> same report. With the regular version, pass =User!UserID into the query
> parameter. In the manager's version, populate the same parameter from a
> drop-down list. Then set different permissions when you deploy the reports.
> If you need to do it in a single report, you might be able to write some
> custom code to pass in flags to the query and work out the difference
> between managers and employees in your data source query.
> --
> Cheers,
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---|||To protect it on the back side (from someone simply altering the URL to look
at someone else's data) you could always create a permissions table that
contains all of the usernames that each user is allowed to look at, and have
that table always be in the source query join, with User!UserID passed into
the query. We're doing a variation on this (a join to a parameterized UDF)
for our data security solution.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"jgephart" <jgephart@.discussions.microsoft.com> wrote in message
news:F5C7BDD7-4F0D-488C-80CB-7F81201B08A4@.microsoft.com...
> Thanks, Jeff. This will affect a whole series of reports, so I don't
> really
> want to maintain separate versions. I think I'm going to be able to go
> with
> passing in User!UserID to the query that builds the drop-down list of
> users.
> I can't hide the drop-down list, but at least I can make sure it's only
> populated with a single user if that user doesn't have permission to see
> other people's data.
>
> "Jeff A. Stucker" wrote:
>> The easiest way I can think of to manage this is to have two versions of
>> the
>> same report. With the regular version, pass =User!UserID into the query
>> parameter. In the manager's version, populate the same parameter from a
>> drop-down list. Then set different permissions when you deploy the
>> reports.
>> If you need to do it in a single report, you might be able to write some
>> custom code to pass in flags to the query and work out the difference
>> between managers and employees in your data source query.
>> --
>> Cheers,
>> '(' Jeff A. Stucker
>> \
>> Business Intelligence
>> www.criadvantage.com
>> ---|||You could use linked reports instead, possibly in conjunction with the
My Reports feature. Linked reports are effectively shortcuts to a
report.
But, the nice touch is that you can set the parameters to behave a bit
differently, for instance there is a prompt user check box on each
parameter in the linked reports properties. This doesn't affect the
original report. If you update the original, the linked report will
reflect these changes too. Security can be set completely independantly
too.
Chris
Jeff A. Stucker wrote:
> To protect it on the back side (from someone simply altering the URL
> to look at someone else's data) you could always create a permissions
> table that contains all of the usernames that each user is allowed to
> look at, and have that table always be in the source query join, with
> User!UserID passed into the query. We're doing a variation on this
> (a join to a parameterized UDF) for our data security solution.sql

Hi need help to decide the indexers

Hello,

I have a situation here...

where we are inserting data of candidate...which includes fields...

1. First Name, Middle Name, Last Name ... (varchar(50))

2. Passport ID (no duplicates allowed but may be null )

3. Telephone number... ( may be null but no duplicates allowed )

4. Date of Birth ( mandatory )

5. Email id .......(no duplicates allowed but may be null )

The problem is that we already have about 1 lakh enteries in the database..

and it is expected to grow with time...

We need to define indexers such that it doesnot take time for searching or while inserting a new datafield into the database.

I hope that i am clear.

since, i suspect that that as it grows it will become more and more slow...!

This is database to store "resumes of different candidates".

So have decided...that

1. name 2. Passport no. 3. Email id: 4. Contact number

be the fields to prevent duplicacy of candidate data...

This involves checking for candidates existence every time anybody tries to make a new entry into database.

Please help to decide over the indexers...

Any good suggestions are welcomed...

Thanks for the reply...

\With regards,

Girish R. Pawar

You could easily have dupicates for Name. I would most certainly break the name into at least LastName and FirstName.

Two candidates 'could' be sharing a contact telephone number, so your 'no duplicates' constraint may be a problem.

I will often have an 'Age' field on the input form (BUT it isn't saved to the database) -it acts as a 'cross-check' against the DOB. DOB is so critical in some situations, we want to catch the obvious 'transpositions' immediately.

Your choices of indexes seem reasonable.