Hello,

we use Llbl Vrs. 4.2 on .NET 4.0 Framework. We have an important project with very old classes / libraries inherited from a project converted to VB6 using CodeArchitects ADOLibrary and VBLibrary.

Obviously, if we could, we would have already abandoned these libraries, but for technical reasons this is not possible at present. We try to do the new implementations with Llbl, however in the case, for example, of ongoing transactions we do not know how to retrieve the same connection and use it in Llbl.

It's possible? Specifically, the ADO object in question is the ADOConnection object. How can we refer to the same transaction via Llbl objects?

Thank you in advance

mcarugati wrote:

Hello,

we use Llbl Vrs. 4.2 on .NET 4.0 Framework. We have an important project with very old classes / libraries inherited from a project converted to VB6 using CodeArchitects ADOLibrary and VBLibrary.

Obviously, if we could, we would have already abandoned these libraries, but for technical reasons this is not possible at present. We try to do the new implementations with Llbl, however in the case, for example, of ongoing transactions we do not know how to retrieve the same connection and use it in Llbl.

It's possible? Specifically, the ADO object in question is the ADOConnection object. How can we refer to the same transaction via Llbl objects?

Thank you in advance

If you're using SelfServicing, you can pass along the Transaction object that forms the transaction. if you're using adapter (recommended) you can pass along the DataAccessAdapter object which contains the transaction. This forum for instance uses that concept too: https://github.com/SolutionsDesign/HnD/blob/master/BL/MessageManager.cs#L50 here we create an adapter which is passed to other methods to perform work, the methods there don't commit the transaction.

Another possibility to solve this is to use a Unit of work object (SelfServicing: UnitOfWork, adapter: UnitOfWork2), which collects work like saving, deleting etc. and then you can commit it in one go (in one transaction). See docs

Otis wrote:

If you're using adapter (recommended) you can pass along the DataAccessAdapter object which contains the transaction. This forum for instance uses that concept too: https://github.com/SolutionsDesign/HnD/blob/master/BL/MessageManager.cs#L50 here we create an adapter which is passed to other methods to perform work, the methods there don't commit the transaction.

Hi Otis,

thanks for the answer, but forgive me: I'm afraid I haven't explained the problem well (or I didn't understand the answer). The "DeleteMessageAsync" method you indicated in the example uses a DataAccessAdapter which manages the transaction.

In our case the transaction already exists and is managed by an ADOConnect object. We would need to be able to instantiate an Adapter using the same transaction as the ADOConnect object. It's possible? Do you have an example to give us?

Thank you very much

mcarugati wrote:

Otis wrote:

If you're using adapter (recommended) you can pass along the DataAccessAdapter object which contains the transaction. This forum for instance uses that concept too: https://github.com/SolutionsDesign/HnD/blob/master/BL/MessageManager.cs#L50 here we create an adapter which is passed to other methods to perform work, the methods there don't commit the transaction.

Hi Otis,

thanks for the answer, but forgive me: I'm afraid I haven't explained the problem well (or I didn't understand the answer). The "DeleteMessageAsync" method you indicated in the example uses a DataAccessAdapter which manages the transaction.

In our case the transaction already exists and is managed by an ADOConnect object. We would need to be able to instantiate an Adapter using the same transaction as the ADOConnect object. It's possible? Do you have an example to give us?

An ADOConnect object is a COM based ADO object, correct? As our system is .net and not usable with ADO objects but with ADO.NET objects (which is a different system: VB6 uses ADO which are OleDB objects and .NET uses ADO.NET which are their own set of classes and aren't related to the ADO objects of the VB days)

Otis wrote:

An ADOConnect object is a COM based ADO object, correct? As our system is .net and not usable with ADO objects but with ADO.NET objects (which is a different system: VB6 uses ADO which are OleDB objects and .NET uses ADO.NET which are their own set of classes and aren't related to the ADO objects of the VB days)

I confirm that the "ADOConnection" object is a .NET object which makes available Framework objects such as System.Data.SqlClient.SqlConnection , System.Data.Common.DbTransaction , and similar.

Starting from these .NET objects, is it possible to instantiate a Llbl Adapter that uses the same existing transaction?

Thank you

mcarugati wrote:

Otis wrote:

An ADOConnect object is a COM based ADO object, correct? As our system is .net and not usable with ADO objects but with ADO.NET objects (which is a different system: VB6 uses ADO which are OleDB objects and .NET uses ADO.NET which are their own set of classes and aren't related to the ADO objects of the VB days)

I confirm that the "ADOConnection" object is a .NET object which makes available Framework objects such as System.Data.SqlClient.SqlConnection , System.Data.Common.DbTransaction , and similar.

Starting from these .NET objects, is it possible to instantiate a Llbl Adapter that uses the same existing transaction?

With a bit of coding, yes. In a partial class of DataAccessAdapter(which is generated) override the method CreateNewPhysicalConnection (see docs)and there return the DbConnection instance you want to re-use, which you e.g. set on a property you add to the partial class as well. So in the override of that method you check if the property is set to an instance, if so, return that, otherwise return the base method's return value. You can do the same for the CreateNewPhysicalTransaction method.

It might be wise to keep things separated however, but if you must integrate two systems, this is the way to do it.

Otis wrote:

With a bit of coding, yes. In a partial class of DataAccessAdapter(which is generated) override the method CreateNewPhysicalConnection (see docs)and there return the DbConnection instance you want to re-use, which you e.g. set on a property you add to the partial class as well. So in the override of that method you check if the property is set to an instance, if so, return that, otherwise return the base method's return value. You can do the same for the CreateNewPhysicalTransaction method.

It might be wise to keep things separated however, but if you must integrate two systems, this is the way to do it.

We will try this approach, it was just the kind of solution we envisioned and were looking for. Thanks a lot Otis