[AccessD] Upsizing (was: Desperately Seeking!)

<b></b>
Hi Arthur

Hmm - are we on the same channel? Over.

I just can't see why the second case here:

>         Faculty_ID = @Faculty_ID AND School_ID = @School_ID
>         OR
>         Faculty_ID = @Faculty_ID
>         OR
>         @Faculty_ID = 'All'

will NOT return True for any record of a given Faculty_ID no matter
what School_ID you pass? 

/gustav


> Which is exactly why we need the third case, because some people have access
> only to one faculty and one school within it. The second case deals with
> people who have faculty access and all schools within it. The first case
> deals with 'All', 'All'.

> Unless I'm missing something, which has happened before and will doubtless
> again.


> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
> Sent: May 4, 2003 12:29 PM
> To: accessd at databaseadvisors.com
> Subject: Re: [AccessD] Upsizing (was: Desperately Seeking!)


> Hi Arthur

>> You've omitted the third case, where say Faculty = 'FB' and School = 
>> 'BM'. Some users cannot see their whole faculty, just their school.

> That's what I suspected - but the second case will return True for those
> records of a given Faculty no matter what School ... ??

> /gustav


>> Hi Arthur

>> Haven't followed this thread closely, but wonder how:

>>>         Faculty_ID = @Faculty_ID AND School_ID = @School_ID
>>>         OR
>>>         Faculty_ID = @Faculty_ID
>>>         OR
>>>         @Faculty_ID = 'All'

>> would differ from:

>>>         Faculty_ID = @Faculty_ID
>>>         OR
>>>         @Faculty_ID = 'All'

>> /gustav


>>> Glad you noticed and glad to share it. It's just one of those
>>> slaps-aside-the-head that we occasionally need. In this case, it's the 
>>> assumption that you test parms against column values. But suppose you 
>>> reject this notion. Case in recent point, there are two columns called 
>>> Faculty_ID and School_ID, so that the permutations might be something 
>>> like this:

>>> FB      BM
>>> FB      All
>>> All     All

>>> The "scope" values are in a table called tblUsers. You grab the 
>>> values
>>> for the current user from there and apply them to a single sproc that 
>>> covers all cases. Like so:

>>> SELECT * FROM someTable(s)
>>> WHERE
>>>         Faculty_ID = @Faculty_ID AND School_ID = @School_ID
>>>         OR
>>>         Faculty_ID = @Faculty_ID
>>>         OR
>>>         @Faculty_ID = 'All'

>>> This grabs all possible combinations.

>>> The point is, you can test parms against values rather than column
>>> contents, as in the last line.


>>> A.

>>> -----Original Message-----
>>> From: accessd-bounces at databaseadvisors.com
>>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
>>> Sent: May 3, 2003 2:08 PM
>>> To: accessd at databaseadvisors.com
>>> Subject: RE: [AccessD] Upsizing (was: Desperately Seeking!)


>>> Arthur,

>>> The scenario I described is pretty much limited to a LAN situation, 
>>> not a WAN.  I can see why a WAN database may work better with an 
>>> unbound database.

>>> But what I really am calling about is the "All" argument.  Could you 
>>> replay with an example?  This sounds like it could be really valuable.