[AccessD] Upsizing (was: Desperately Seeking!)

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.

> Thanks!
> Dan Waters