Activity overview
Latest activity by gizdoc
I actually ran into something very similar while building a keyboard tester desktop app that switches between a local SQL Server instance and Azure SQL Database. On SQL Server, everything worked fine with just stored procedures and no direct SELECT permissions, thanks to ownership chaining. But in Azure SQL DB (with Entra ID), I started getting SELECT permission errors inside stored procedures even though DELETE and UPDATE worked without issues exactly like what you're describing. From what I found, Azure SQL can behave a bit stricter depending on execution context, ownership alignment, and how the user is mapped via Entra ID. If the proc and tables don’t share the same owner or if EXECUTE AS isn’t set properly, ownership chaining might not apply the same way. Also worth double-checking role assignments because Azure sometimes doesn't mirror on-prem behavior perfectly even when schemas are identical. In my case, explicitly granting SELECT fixed it, but it does feel like it goes against the usual least-privilege approach we follow on SQL Server. Definitely interested if someone has a deeper explanation for this difference. / comments
I actually ran into something very similar while building a keyboard tester desktop app that switches between a local SQL Server instance and Azure SQL Database. On SQL Server, everything worked fi...