A SELECT statement run under one database login (like IFSINFO) needs to call API functions that are only granted under a different schema (like IFSAPP) — granting EXECUTE on those specific packages to the IFSINFO login doesn't error, but the query just silently returns zero rows instead of the expected data. Is there a safe way to grant an account like IFSINFO execute access to another schema's APIs, including whatever underlying tables/views those APIs themselves depend on?

All FAQ questions / Security and access

Answer

Be cautious about doing this at all — opening up execute access to objects that aren't normally granted to a reporting-oriented login like IFSINFO risks reports/IALs built on it exposing more data to standard users than intended, since that account is meant to have a deliberately narrower, read-oriented scope. Before assuming it's purely a missing-grant problem, consider that a silent zero-rows result (with no privilege error) is often actually a scoping/filter issue rather than a permissions issue — for example, if the underlying view has a company or similar context filter baked into its definition, and the calling login's context doesn't match, it can return zero rows perfectly legitimately even with full execute/select access. It is technically possible to grant broader access, but doing so for a shared, purpose-scoped account like IFSINFO isn't recommended.

Documentation-based answer. Confirm the product and release before applying it. This answer has not been verified in an IFS environment.

← Browse Security and access questions