Home/ Questions/Q 543199
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T10:31:35+00:00

There’s an app that starts a transaction on SQL Server 2008 and moves some

  • 0

There’s an app that starts a transaction on SQL Server 2008 and moves some data around. Then, while the transaction is still not committed, the app prints out some labels. It is very important that the transaction is not committed until printing succeeded; if a printing error occurs, everything is rolled back.

Now, the printing engine is a) grew quite huge and complex, and b) is eventually required from lots of places. It is therefore decided to separate the engine and make it a service.

Yes, it is possible to pass all data required for printing from the client app to that server so that the server only prints and is not concerned about databases. However, that would mean leaving piles of code and label templates in each application that requires printing; effectively, very little separation will then occur. On contrary, it would be extreemely efficient (and easier for me to write and maintain) to just pass the IDs of what is required to the service which then would go to the database and get the data. All formats and layouts will be centralized and apps will only ask for 5 delivery notes from print job 12345.

Now, this is not going to happen as the transaction is still not committed at the moment of printing. The service would not be able to read the data, and using READ UNCOMMITTED is not quite an option.

I was going to use the good old sp_bindsession to join the two sessions, app’s and service’s, but then it is suddenly deprecated and to be removed from future releases. The help suggests I use MARS or distributed transactions instead, but I can’t see how they would help.

Any advice?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    My gut feeling is that attempting to share a transaction between two processes in this way is not a good idea.

    My approach would be to either to pass all data to service, or investigate alternatives to keeping the transaction open for the duration of the printing – would a simpler mechanism (such as an IsPrinted flag for each record) not suffice?

    Failing that, the eaisest way I can see of doing this would be to have the printing service pass all of its SQL requests back through to the originating process so that they can be executed in the context of the original transaction.

    • 0