I'd like to offer an alternative opinion of your concept, just as food for thought:  

The application server for X3 is responsible for issuing the open and close of a transaction boundary. So, if you provide control to the end user to kill a SQL process ID (SPID), said end user is essentially usurping the control of the transaction boundary. So, now you've transferred ownership of the validation and business logic of Sage ERP X3 to an end user. I'd be concerned with data integrity in this scenario. The proper technique for this is to use the user monitor to end a process (PSADX).

Moreover, from a security standpoint killing a SPID on a SQL Server is an administration level event. So if you were to write a web page that gave control to an end user to do that, you would essentially be providing sysadmin control over your SQL Server to anyone who had access to the web page. You could potentially open up your system to SQL injection attacks depending on how you write the web page. Specifically, the web page user would have elevated control over your SQL Server. If you are interfacing with credit card processing in any way you might not pass a credit card audit either (means your bank fees go up).

If you wanted, you could give access to the user monitor instead. Usually admins have access to that tool, but you can design your security in a way that suits your needs.

Hope this helps.

I'd like to offer an alternative opinion of your concept, just as food for thought:  

The application server for X3 is responsible for issuing the open and close of a transaction boundary. So, if you provide control to the end user to kill a SQL process ID (SPID), said end user is essentially usurping the control of the transaction boundary. So, now you've transferred ownership of the validation and business logic of Sage ERP X3 to an end user. I'd be concerned with data integrity in this scenario. The proper technique for this is to use the user monitor to end a process (PSADX).

Moreover, from a security standpoint killing a SPID on a SQL Server is an administration level event. So if you were to write a web page that gave control to an end user to do that, you would essentially be providing sysadmin control over your SQL Server to anyone who had access to the web page. You could potentially open up your system to SQL injection attacks depending on how you write the web page. Specifically, the web page user would have elevated control over your SQL Server. If you are interfacing with credit card processing in any way you might not pass a credit card audit either (means your bank fees go up).

If you wanted, you could give access to the user monitor instead. Usually admins have access to that tool, but you can design your security in a way that suits your needs.

Hope this helps.

Delamater,

It would be an intranet scenario only, using the proper params to a proc to avoid a sql injections, AD logins would match the sage login so their only option would be to delete "their" sessions - and not those of others.

Lately our provider has been going up and down and resulting in hung sessions. If possible I'd like to empower the end user to help themselves and get back to their day is all.

thanks for your thoughts on the subject.

much appreciated.

Jeff