[AccessD] Upsizing (was: Desperately Seeking!)

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