I am curious as to the best approach to take regarding when to call Adapter.StartTransaction.

There are basically 2 approaches that one could take when performing multiple CRUD operations on a set of related entities.

** Option A** Create a parent entity and attach all related entities to it, then call Adapter.SaveEntity(), use the proper overload and the entity, all key values, and all related entities should be created. (Atleast I think thats how it works)

** Option B** Create a parent entity, save it using Adapter.SaveEntity, refetch the key values. Pass the key values on, create the related entitties (either via collection or one at a time) then save them.

Typically, most people create transactions as late as possible and close them as soon as possible, just like connections.

When you look at the samples in the help, you typically see transactional code like this:

dim myDB as new DataAccessAdapter
myDB.StartTransaction

Try
   '.....Do Some Work
   myDB.Commit
Catch 
   myDB.RollBack
Finally 
    myDB.Dispose
End Try

If I code using the practices outlined in option A, could you not write your code like this:

dim myDB as DataAccessAdapter

Try
   '.....Do Some Work / build some entities and set their properties
   myDB = new DataAccessAdapter
   myDB.StartTransaction
   if myDB.SaveEntity(someEntity, False, Nothing, True) then
      myDB.Commit
   end if
Catch 
   myDB.RollBack
Finally 
    myDB.Dispose
End Try

Writing code using option B would pretty much require coding your transaction like the first code sample, because the methods called for related entities physically interact with the database

Is there anthing that we should know about regarding how the StartTransaction method works internally?

StartTransaction opens the connection and creates an ADO.NET transaction object. It also associates every entity or entity collection with that transaction, so entities will internally roll back as well when the transaction rolls back.

So basicly it's a pretty thin method. (you can see the source in the runtime sourcecode which is available in teh customer area btw ).

You should perform transactions as late as possible and preferably without interference. So you basicly take these steps: - collect data for the transaction actions - start the transaction - perform the actions on the data collected - commit/roll back the transaction, based on the results of the actions

The reason for this is that you have the most scalable application: during a transaction, the database will lock resources (not on Oracle per se, as Oracle uses MVCC, which doesn't lock rows written during a transaction) and the longer the transaction takes, the longer other threads/users can't read the data in the locked rows and are put on hold.

It also makes your code more cleaner: you have a tiny pack of actions to perform and they're all located on the same spot.