Re: Cross Transactions between ADO & ADO.Net

There is one thing that might help here, if you're using SQL Server. This is
a feature that we don't advertise a lot and we've been removing the focus
from it over time; so read on if you need this as an intermediate step while
you migrate your app, *not* as a long-term solution:

SQL Server supports something called "bound sessions", where two connections
(to the same server) can be bound to the same transaction, without involving
a distributed transaction coordinator. Bound sessions require careful
coordination, as while you use one (e.g. have a pending data-reader) you
cannot use the other. If those limitations are ok with you, then you can
find out how to use bound sessions in SQL Server Books Online (it's fairly
easy), start by looking at the sections for "sp_getbindtoken" and
"sp_bindsession"

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.


"Brent" <brentwa@xxxxxxxxxxxxxxxx> wrote in message
news:u1ChPVDcFHA.2696@xxxxxxxxxxxxxxxxxxxxxxx
> Hi, we are changing our application from VB6 to VB.Net. This is far from a
> trivial upgrade. We have over 400 forms and 40 dll's. We can't just take
> down our production application and start the whole project from scratch.
> We have to convert this stuff in stages. Our application design is pretty
> much 2-tier. We connection to SQL server when the application starts and
> then disconnect when the application unloads. We even call ADO code from
> our dll so transactions are scattered all over the code between dll's and
> the main application. I guess the problem comes in when we are upgrade
> some code will be ADO & some code will be ADO.Net. I came up with an idea
> which i think would work which would be to hose both our ADO object ( a
> wrapper we wrote for ADO) and ADO.Net wrapper in COM+. We could then use
> the DTC cordinator from COM+ to handle the transactions between ADO.Net &
> plain ADO for us.
>
> Does anyone see a better solution. The solution i came up with would
> require two connections to the DB and if possible we would like a solution
> only requiring one conneciton. We are also concerned about throughput
> since COM+ transactions are at a layer above ADO transactions and we don't
> want any bottlenecks in our new code if possible. Does anyone have any
> better solutions?
>
> thanks,
> Brent
>


.

Relevant Pages

  • Re: Cross Transactions between ADO & ADO.Net
    ... MARS session pool limited to one connection?). ... > There is one thing that might help here, if you're using SQL Server. ... We even call ADO code from ... >> the DTC cordinator from COM+ to handle the transactions between ADO.Net ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Strange SQL 2000 connections ! (ghost connections)
    ... I no longer like to comment on Access/JET database issues--there are simply ... Access/JET is a very challenged interface to SQL Server. ... I think that the 'ghost' connections are unrelated to your problems. ... If you find any open transactions that are more than a few minutes old, ...
    (microsoft.public.sqlserver.connect)
  • SQL Server backend poor performance
    ... I have converted an Access back-end to SQL Server back-end but am ... I have successfully copied all the data to SQL Server and linked the ... in the number of connections the whole system grinds to a halt. ... I am using DAO but wonder whether I should move over to ADO. ...
    (comp.databases.ms-access)
  • app roles and ADO connections
    ... I'm having problems with the combination of SQL Server ... application roles and ADO connections. ... problematic since the approles is strictly a SQL Server ... In some cases ADO will create additional connections ...
    (microsoft.public.sqlserver.security)
  • Re: Win32.client, DAO.DBEngine and exceeding the file sharing count lock
    ... (scroll down to table 7.1) ... transactions, I'd suggest that you move to SQL Server for processing ... to which said ADO couldn't was a posting which refuted some of the ...
    (comp.lang.python)