-
David Peace -Consulting Partner Powersoft
- PowerServer
- Thursday, 30 July 2026 12:33 PM UTC
I have been musing a Powerserver migration problem, relating to data i the DB Session Context for that user.... e.g. UserName, Application Version.
Problem: Our app uses a single shared SQL login (common with PowerServer's pooled connections) plus DB-level audit triggers that need to know the real end user details. Triggers only see the shared login, and pooling means anything set on the connection (CONTEXT_INFO/SESSION_CONTEXT) can't be trusted to survive to the next call — a known issue (see "Set Context_info in PowerServer"). Workarounds like LongConnection or the new SQLPreview support in 2025 help, but either give up pooling or only cover DataWindow DML, not raw embedded SQL.
Request: When PowerServer hands a connection to a request, have it automatically stamp its own session ID onto that connection (e.g. sp_set_session_context) before running any app SQL. PowerServer already tracks this ID (GetApplication().GetSessionID()) — it just needs to reach the DB session too.
This would work for all PB apps: We'd map that session ID to our own users in our own session table — no PowerServer-side app knowledge needed. Any customer with a shared DB login and an audit requirement (very common) hits this same gap; this fix solves it for everyone without disabling pooling or touching legacy code.
What do you guys think? If you think it is a valid solution then I can raise an enhancement request?
Thanks for your thoughts
David
Find Questions by Tag
Helpful?
If a reply or comment is helpful for you, please don’t hesitate to click the Helpful button. This action is further confirmation of their invaluable contribution to the Appeon Community.