Rights on sproc with dynamic sql

I have a sproc z on on which user x has execute rights.
The sproc z dynamically builds a sql statement based on input param.
The sql quey table y on which user x does not have execute rights.
When the sql is executed at the end of the sproc I get an error saying
that "user x does not have exec rights on table y".
Shouldn't it be sufficient to grant user x exec rights on sproc z?
/M
Not when you're using dynamic sql. Thats one of the problems. Dynamic sql is
executed in the security context of the user, while 'normal' sql is executed
in the security context of the sp owner (usually dbo).
Or, to bi more precise, grantable permissions are executed in the owner
context. You cant grant permission to execute dynamic sql and it is executed
as user...
MC
<job@.bla.com> wrote in message
news:gq80129hctb468t8hfbe40lahsmagad4gh@.4ax.com...
>I have a sproc z on on which user x has execute rights.
> The sproc z dynamically builds a sql statement based on input param.
> The sql quey table y on which user x does not have execute rights.
> When the sql is executed at the end of the sproc I get an error saying
> that "user x does not have exec rights on table y".
> Shouldn't it be sufficient to grant user x exec rights on sproc z?
> /M
|||Hmm. Thanks. Guess I'll have to rethink my approach
On Thu, 9 Mar 2006 14:15:01 +0100, "MC" <marko_culo#@.#yahoo#.#com#>
wrote:

>Not when you're using dynamic sql. Thats one of the problems. Dynamic sql is
>executed in the security context of the user, while 'normal' sql is executed
>in the security context of the sp owner (usually dbo).
>Or, to bi more precise, grantable permissions are executed in the owner
>context. You cant grant permission to execute dynamic sql and it is executed
>as user...
>
>MC
><job@.bla.com> wrote in message
>news:gq80129hctb468t8hfbe40lahsmagad4gh@.4ax.com.. .
>
|||> Not when you're using dynamic sql. Thats one of the problems. Dynamic sql
> is executed in the security context of the user, while 'normal' sql is
> executed in the security context of the sp owner (usually dbo).
It is a common misconception that the security context is the owner. The
actual behavior is that permissions on indirectly referenced objects are not
checked at all when the ownership chain is unbroken (all objects owned by
the same user). Dynamic SQL is considered a direct object reference so user
permissions are checked just like when the ownership chain is broken.
SQL Server 2005 introduces EXECUTE AS but ownership chains still apply and
take precedence. See http://www.sommarskog.se/grantperm.html.
Hope this helps.
Dan Guzman
SQL Server MVP
"MC" <marko_culo#@.#yahoo#.#com#> wrote in message
news:uZGzwm3QGHA.3052@.TK2MSFTNGP09.phx.gbl...
> Not when you're using dynamic sql. Thats one of the problems. Dynamic sql
> is executed in the security context of the user, while 'normal' sql is
> executed in the security context of the sp owner (usually dbo).
> Or, to bi more precise, grantable permissions are executed in the owner
> context. You cant grant permission to execute dynamic sql and it is
> executed as user...
>
> MC
> <job@.bla.com> wrote in message
> news:gq80129hctb468t8hfbe40lahsmagad4gh@.4ax.com...
>
|||Does that mean that deny on table to table_owner woudlnt actually be
effective if the table_owner is the sp owner as well?
MC
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:OmaDO03QGHA.4696@.tk2msftngp13.phx.gbl...
> It is a common misconception that the security context is the owner. The
> actual behavior is that permissions on indirectly referenced objects are
> not checked at all when the ownership chain is unbroken (all objects owned
> by the same user). Dynamic SQL is considered a direct object reference so
> user permissions are checked just like when the ownership chain is broken.
> SQL Server 2005 introduces EXECUTE AS but ownership chains still apply and
> take precedence. See http://www.sommarskog.se/grantperm.html.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "MC" <marko_culo#@.#yahoo#.#com#> wrote in message
> news:uZGzwm3QGHA.3052@.TK2MSFTNGP09.phx.gbl...
>
|||It serves no purpose to DENY object permissions to the object owner since
the owner always has full permissions anyway. In any case, I know of no
exceptions to the ownership chain rule - permissions are not checked when
the chain is unbroken.
Hope this helps.
Dan Guzman
SQL Server MVP
"MC" <marko_culo#@.#yahoo#.#com#> wrote in message
news:%23OaJoF4QGHA.4452@.TK2MSFTNGP12.phx.gbl...
> Does that mean that deny on table to table_owner woudlnt actually be
> effective if the table_owner is the sp owner as well?
>
> MC
>
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:OmaDO03QGHA.4696@.tk2msftngp13.phx.gbl...
>
|||Ok, thanks for explaining.
MC
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:erVTCW%23QGHA.5584@.TK2MSFTNGP12.phx.gbl...
> It serves no purpose to DENY object permissions to the object owner since
> the owner always has full permissions anyway. In any case, I know of no
> exceptions to the ownership chain rule - permissions are not checked when
> the chain is unbroken.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "MC" <marko_culo#@.#yahoo#.#com#> wrote in message
> news:%23OaJoF4QGHA.4452@.TK2MSFTNGP12.phx.gbl...
>

Rights on sproc with dynamic sql

I have a sproc z on on which user x has execute rights.
The sproc z dynamically builds a sql statement based on input param.
The sql quey table y on which user x does not have execute rights.
When the sql is executed at the end of the sproc I get an error saying
that "user x does not have exec rights on table y".
Shouldn't it be sufficient to grant user x exec rights on sproc z?
/MNot when you're using dynamic sql. Thats one of the problems. Dynamic sql is
executed in the security context of the user, while 'normal' sql is executed
in the security context of the sp owner (usually dbo).
Or, to bi more precise, grantable permissions are executed in the owner
context. You cant grant permission to execute dynamic sql and it is executed
as user...
MC
<job@.bla.com> wrote in message
news:gq80129hctb468t8hfbe40lahsmagad4gh@.
4ax.com...
>I have a sproc z on on which user x has execute rights.
> The sproc z dynamically builds a sql statement based on input param.
> The sql quey table y on which user x does not have execute rights.
> When the sql is executed at the end of the sproc I get an error saying
> that "user x does not have exec rights on table y".
> Shouldn't it be sufficient to grant user x exec rights on sproc z?
> /M|||Hmm. Thanks. Guess I'll have to rethink my approach
On Thu, 9 Mar 2006 14:15:01 +0100, "MC" <marko_culo#@.#yahoo#.#com#>
wrote:

>Not when you're using dynamic sql. Thats one of the problems. Dynamic sql i
s
>executed in the security context of the user, while 'normal' sql is execute
d
>in the security context of the sp owner (usually dbo).
>Or, to bi more precise, grantable permissions are executed in the owner
>context. You cant grant permission to execute dynamic sql and it is execute
d
>as user...
>
>MC
><job@.bla.com> wrote in message
> news:gq80129hctb468t8hfbe40lahsmagad4gh@.
4ax.com...
>|||> Not when you're using dynamic sql. Thats one of the problems. Dynamic sql
> is executed in the security context of the user, while 'normal' sql is
> executed in the security context of the sp owner (usually dbo).
It is a common misconception that the security context is the owner. The
actual behavior is that permissions on indirectly referenced objects are not
checked at all when the ownership chain is unbroken (all objects owned by
the same user). Dynamic SQL is considered a direct object reference so user
permissions are checked just like when the ownership chain is broken.
SQL Server 2005 introduces EXECUTE AS but ownership chains still apply and
take precedence. See http://www.sommarskog.se/grantperm.html.
Hope this helps.
Dan Guzman
SQL Server MVP
"MC" <marko_culo#@.#yahoo#.#com#> wrote in message
news:uZGzwm3QGHA.3052@.TK2MSFTNGP09.phx.gbl...
> Not when you're using dynamic sql. Thats one of the problems. Dynamic sql
> is executed in the security context of the user, while 'normal' sql is
> executed in the security context of the sp owner (usually dbo).
> Or, to bi more precise, grantable permissions are executed in the owner
> context. You cant grant permission to execute dynamic sql and it is
> executed as user...
>
> MC
> <job@.bla.com> wrote in message
> news:gq80129hctb468t8hfbe40lahsmagad4gh@.
4ax.com...
>|||Does that mean that deny on table to table_owner woudlnt actually be
effective if the table_owner is the sp owner as well?
MC
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:OmaDO03QGHA.4696@.tk2msftngp13.phx.gbl...
> It is a common misconception that the security context is the owner. The
> actual behavior is that permissions on indirectly referenced objects are
> not checked at all when the ownership chain is unbroken (all objects owned
> by the same user). Dynamic SQL is considered a direct object reference so
> user permissions are checked just like when the ownership chain is broken.
> SQL Server 2005 introduces EXECUTE AS but ownership chains still apply and
> take precedence. See http://www.sommarskog.se/grantperm.html.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "MC" <marko_culo#@.#yahoo#.#com#> wrote in message
> news:uZGzwm3QGHA.3052@.TK2MSFTNGP09.phx.gbl...
>|||It serves no purpose to DENY object permissions to the object owner since
the owner always has full permissions anyway. In any case, I know of no
exceptions to the ownership chain rule - permissions are not checked when
the chain is unbroken.
Hope this helps.
Dan Guzman
SQL Server MVP
"MC" <marko_culo#@.#yahoo#.#com#> wrote in message
news:%23OaJoF4QGHA.4452@.TK2MSFTNGP12.phx.gbl...
> Does that mean that deny on table to table_owner woudlnt actually be
> effective if the table_owner is the sp owner as well?
>
> MC
>
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:OmaDO03QGHA.4696@.tk2msftngp13.phx.gbl...
>|||Ok, thanks for explaining.
MC
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:erVTCW%23QGHA.5584@.TK2MSFTNGP12.phx.gbl...
> It serves no purpose to DENY object permissions to the object owner since
> the owner always has full permissions anyway. In any case, I know of no
> exceptions to the ownership chain rule - permissions are not checked when
> the chain is unbroken.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "MC" <marko_culo#@.#yahoo#.#com#> wrote in message
> news:%23OaJoF4QGHA.4452@.TK2MSFTNGP12.phx.gbl...
>sql

Rights on sproc with dynamic sql

I have a sproc z on on which user x has execute rights.
The sproc z dynamically builds a sql statement based on input param.
The sql quey table y on which user x does not have execute rights.
When the sql is executed at the end of the sproc I get an error saying
that "user x does not have exec rights on table y".
Shouldn't it be sufficient to grant user x exec rights on sproc z?
/MNot when you're using dynamic sql. Thats one of the problems. Dynamic sql is
executed in the security context of the user, while 'normal' sql is executed
in the security context of the sp owner (usually dbo).
Or, to bi more precise, grantable permissions are executed in the owner
context. You cant grant permission to execute dynamic sql and it is executed
as user...
MC
<job@.bla.com> wrote in message
news:gq80129hctb468t8hfbe40lahsmagad4gh@.4ax.com...
>I have a sproc z on on which user x has execute rights.
> The sproc z dynamically builds a sql statement based on input param.
> The sql quey table y on which user x does not have execute rights.
> When the sql is executed at the end of the sproc I get an error saying
> that "user x does not have exec rights on table y".
> Shouldn't it be sufficient to grant user x exec rights on sproc z?
> /M|||Hmm. Thanks. Guess I'll have to rethink my approach :(
On Thu, 9 Mar 2006 14:15:01 +0100, "MC" <marko_culo#@.#yahoo#.#com#>
wrote:
>Not when you're using dynamic sql. Thats one of the problems. Dynamic sql is
>executed in the security context of the user, while 'normal' sql is executed
>in the security context of the sp owner (usually dbo).
>Or, to bi more precise, grantable permissions are executed in the owner
>context. You cant grant permission to execute dynamic sql and it is executed
>as user...
>
>MC
><job@.bla.com> wrote in message
>news:gq80129hctb468t8hfbe40lahsmagad4gh@.4ax.com...
>>I have a sproc z on on which user x has execute rights.
>> The sproc z dynamically builds a sql statement based on input param.
>> The sql quey table y on which user x does not have execute rights.
>> When the sql is executed at the end of the sproc I get an error saying
>> that "user x does not have exec rights on table y".
>> Shouldn't it be sufficient to grant user x exec rights on sproc z?
>> /M
>|||> Not when you're using dynamic sql. Thats one of the problems. Dynamic sql
> is executed in the security context of the user, while 'normal' sql is
> executed in the security context of the sp owner (usually dbo).
It is a common misconception that the security context is the owner. The
actual behavior is that permissions on indirectly referenced objects are not
checked at all when the ownership chain is unbroken (all objects owned by
the same user). Dynamic SQL is considered a direct object reference so user
permissions are checked just like when the ownership chain is broken.
SQL Server 2005 introduces EXECUTE AS but ownership chains still apply and
take precedence. See http://www.sommarskog.se/grantperm.html.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"MC" <marko_culo#@.#yahoo#.#com#> wrote in message
news:uZGzwm3QGHA.3052@.TK2MSFTNGP09.phx.gbl...
> Not when you're using dynamic sql. Thats one of the problems. Dynamic sql
> is executed in the security context of the user, while 'normal' sql is
> executed in the security context of the sp owner (usually dbo).
> Or, to bi more precise, grantable permissions are executed in the owner
> context. You cant grant permission to execute dynamic sql and it is
> executed as user...
>
> MC
> <job@.bla.com> wrote in message
> news:gq80129hctb468t8hfbe40lahsmagad4gh@.4ax.com...
>>I have a sproc z on on which user x has execute rights.
>> The sproc z dynamically builds a sql statement based on input param.
>> The sql quey table y on which user x does not have execute rights.
>> When the sql is executed at the end of the sproc I get an error saying
>> that "user x does not have exec rights on table y".
>> Shouldn't it be sufficient to grant user x exec rights on sproc z?
>> /M
>|||Does that mean that deny on table to table_owner woudlnt actually be
effective if the table_owner is the sp owner as well?
MC
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:OmaDO03QGHA.4696@.tk2msftngp13.phx.gbl...
>> Not when you're using dynamic sql. Thats one of the problems. Dynamic sql
>> is executed in the security context of the user, while 'normal' sql is
>> executed in the security context of the sp owner (usually dbo).
> It is a common misconception that the security context is the owner. The
> actual behavior is that permissions on indirectly referenced objects are
> not checked at all when the ownership chain is unbroken (all objects owned
> by the same user). Dynamic SQL is considered a direct object reference so
> user permissions are checked just like when the ownership chain is broken.
> SQL Server 2005 introduces EXECUTE AS but ownership chains still apply and
> take precedence. See http://www.sommarskog.se/grantperm.html.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "MC" <marko_culo#@.#yahoo#.#com#> wrote in message
> news:uZGzwm3QGHA.3052@.TK2MSFTNGP09.phx.gbl...
>> Not when you're using dynamic sql. Thats one of the problems. Dynamic sql
>> is executed in the security context of the user, while 'normal' sql is
>> executed in the security context of the sp owner (usually dbo).
>> Or, to bi more precise, grantable permissions are executed in the owner
>> context. You cant grant permission to execute dynamic sql and it is
>> executed as user...
>>
>> MC
>> <job@.bla.com> wrote in message
>> news:gq80129hctb468t8hfbe40lahsmagad4gh@.4ax.com...
>>I have a sproc z on on which user x has execute rights.
>> The sproc z dynamically builds a sql statement based on input param.
>> The sql quey table y on which user x does not have execute rights.
>> When the sql is executed at the end of the sproc I get an error saying
>> that "user x does not have exec rights on table y".
>> Shouldn't it be sufficient to grant user x exec rights on sproc z?
>> /M
>>
>|||It serves no purpose to DENY object permissions to the object owner since
the owner always has full permissions anyway. In any case, I know of no
exceptions to the ownership chain rule - permissions are not checked when
the chain is unbroken.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"MC" <marko_culo#@.#yahoo#.#com#> wrote in message
news:%23OaJoF4QGHA.4452@.TK2MSFTNGP12.phx.gbl...
> Does that mean that deny on table to table_owner woudlnt actually be
> effective if the table_owner is the sp owner as well?
>
> MC
>
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:OmaDO03QGHA.4696@.tk2msftngp13.phx.gbl...
>> Not when you're using dynamic sql. Thats one of the problems. Dynamic
>> sql is executed in the security context of the user, while 'normal' sql
>> is executed in the security context of the sp owner (usually dbo).
>> It is a common misconception that the security context is the owner. The
>> actual behavior is that permissions on indirectly referenced objects are
>> not checked at all when the ownership chain is unbroken (all objects
>> owned by the same user). Dynamic SQL is considered a direct object
>> reference so user permissions are checked just like when the ownership
>> chain is broken.
>> SQL Server 2005 introduces EXECUTE AS but ownership chains still apply
>> and take precedence. See http://www.sommarskog.se/grantperm.html.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "MC" <marko_culo#@.#yahoo#.#com#> wrote in message
>> news:uZGzwm3QGHA.3052@.TK2MSFTNGP09.phx.gbl...
>> Not when you're using dynamic sql. Thats one of the problems. Dynamic
>> sql is executed in the security context of the user, while 'normal' sql
>> is executed in the security context of the sp owner (usually dbo).
>> Or, to bi more precise, grantable permissions are executed in the owner
>> context. You cant grant permission to execute dynamic sql and it is
>> executed as user...
>>
>> MC
>> <job@.bla.com> wrote in message
>> news:gq80129hctb468t8hfbe40lahsmagad4gh@.4ax.com...
>>I have a sproc z on on which user x has execute rights.
>> The sproc z dynamically builds a sql statement based on input param.
>> The sql quey table y on which user x does not have execute rights.
>> When the sql is executed at the end of the sproc I get an error saying
>> that "user x does not have exec rights on table y".
>> Shouldn't it be sufficient to grant user x exec rights on sproc z?
>> /M
>>
>>
>|||Ok, thanks for explaining.
MC
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:erVTCW%23QGHA.5584@.TK2MSFTNGP12.phx.gbl...
> It serves no purpose to DENY object permissions to the object owner since
> the owner always has full permissions anyway. In any case, I know of no
> exceptions to the ownership chain rule - permissions are not checked when
> the chain is unbroken.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "MC" <marko_culo#@.#yahoo#.#com#> wrote in message
> news:%23OaJoF4QGHA.4452@.TK2MSFTNGP12.phx.gbl...
>> Does that mean that deny on table to table_owner woudlnt actually be
>> effective if the table_owner is the sp owner as well?
>>
>> MC
>>
>> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
>> news:OmaDO03QGHA.4696@.tk2msftngp13.phx.gbl...
>> Not when you're using dynamic sql. Thats one of the problems. Dynamic
>> sql is executed in the security context of the user, while 'normal' sql
>> is executed in the security context of the sp owner (usually dbo).
>> It is a common misconception that the security context is the owner.
>> The actual behavior is that permissions on indirectly referenced objects
>> are not checked at all when the ownership chain is unbroken (all objects
>> owned by the same user). Dynamic SQL is considered a direct object
>> reference so user permissions are checked just like when the ownership
>> chain is broken.
>> SQL Server 2005 introduces EXECUTE AS but ownership chains still apply
>> and take precedence. See http://www.sommarskog.se/grantperm.html.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "MC" <marko_culo#@.#yahoo#.#com#> wrote in message
>> news:uZGzwm3QGHA.3052@.TK2MSFTNGP09.phx.gbl...
>> Not when you're using dynamic sql. Thats one of the problems. Dynamic
>> sql is executed in the security context of the user, while 'normal' sql
>> is executed in the security context of the sp owner (usually dbo).
>> Or, to bi more precise, grantable permissions are executed in the owner
>> context. You cant grant permission to execute dynamic sql and it is
>> executed as user...
>>
>> MC
>> <job@.bla.com> wrote in message
>> news:gq80129hctb468t8hfbe40lahsmagad4gh@.4ax.com...
>>I have a sproc z on on which user x has execute rights.
>> The sproc z dynamically builds a sql statement based on input param.
>> The sql quey table y on which user x does not have execute rights.
>> When the sql is executed at the end of the sproc I get an error saying
>> that "user x does not have exec rights on table y".
>> Shouldn't it be sufficient to grant user x exec rights on sproc z?
>> /M
>>
>>
>>
>

Reusing a Chached Lookup component

Is it possible to reuse a Lookup component which is configured with Full chaching?

My requirement is as follows....

A input file have 2 columns called CurrentLocation and PreviousLocation. In the dataflow, values of these two columns needs to be replaced with values from a look up table called "Location".

In my package i have added two LookUp components which replaces values of CurrentLocation and PreviousLocation with the values available in the table "Location". Is there any way to reuse the cache of first lookup component for second column also?

Hi Gopi,

I guess the answer to your question is negative. It would be a really great feature if a tool allows it.

The otherway is, first 'unpivot' ur data, do the lookup and then 'pivot' it again. This way, u need not cache the data 2 times, though the # of lookups is going to be same.

|||

Thiru,

I'm not able to understand the advantage of performing "unpovit" transformation. How am i going to avoid chaching 2 times? Can you please explain in detail?

Regards,

Gopi

|||

Reuse caching would really be a good way to preserve memmory in the etl process. For instance use it in multiple packages that run parallel in a workflow with each other to load (for instance) fact tables.

Please put the reusability of a lookup on the wishlist.

|||

Hi Gopi,

Assume that your data is like this:

Id CurLoc PrevLoc

1 A X

2 A Y

3 B A

And your Location table is:

Location Id

A 1

B 2

X 24

Y 25

When you unpivot your data based on 'Id' field, it will become,

1 A

1 X

2 A

2 Y

3 B

3 A

Do the lookup and u will get result as

1 1

1 24

2 1

2 25

3 2

3 1

Now, if you pivot it with the 'Id' field, it will become,

1 1 24

2 1 25

3 2 1

As I said, still you have to do the lookup 6 times. But your caching it only once.

|||

Gopinath M wrote:

Is it possible to reuse a Lookup component which is configured with Full chaching?

There is no explicit control over it, but Lookup components do try to share the lookup cache, if they use the same datasource and columns for lookup.

You can check if this actually happen in your case by checking the number of queries in the SQL log.

|||

Thiru,

Your solution works for my case. Thanks you very much for the excellent solution.

Regards,

Gopi

|||

Michael ,

Thank you for providing information.

Regards,

Gopi

Returns 0 rows but which part of the where clause caused it.

I currently have a piece of SQL that will return a row if the input is
valid for the process. My application is a warehouse system. I need to
verify that the thing that is picked for the order can really be used
for that order. It is the correct product, it is in the correct status,
in the correct warehouse, ... Well up until now used one SQL statement
to achieve this. The row was returned or not. If not then the thing
being picked could not be used. Now my boss wants me to return why.
Essentially i will have to get the data and process this in code. Does
anyone have a SQL solution to this? Any tricks anyone uses to determine
which part(s) of the where clause (or join) caused the exclusion?
danWhat if more than 1 condition is FALSE?
There's lots of ways you could implement this, but sooner or later you'll
have to test each condition individually to find the cause.
You could test them up front and not run the query if an "error" condition
is found, or you could run the query and only test the conditions if
@.@.ROWCOUNT = 0.
You could indicate the reason by using RAISERROR, or maintain a table of
error codes and return them in the query, or you could ...
"Dan Holmes" wrote:

> I currently have a piece of SQL that will return a row if the input is
> valid for the process. My application is a warehouse system. I need to
> verify that the thing that is picked for the order can really be used
> for that order. It is the correct product, it is in the correct status,
> in the correct warehouse, ... Well up until now used one SQL statement
> to achieve this. The row was returned or not. If not then the thing
> being picked could not be used. Now my boss wants me to return why.
> Essentially i will have to get the data and process this in code. Does
> anyone have a SQL solution to this? Any tricks anyone uses to determine
> which part(s) of the where clause (or join) caused the exclusion?
> dan
>