Here is my code:

private void UpdateAspireForTransfer()
{
    try
    {
        BusinessLayer.TransactionBegin("Aspire", IsolationLevel.ReadCommitted);
        // Retrieve the next Batch ID
        String mBatchID = GetNextBatchID();
        AssignBatchID(mBatchID);
        CreateCommissions(mBatchID);
        BusinessLayer.TransactionCommit("Aspire");
        UpdateDynamicsForTransfer(mBatchID);
    }
    catch
    {
        BusinessLayer.TransactionRollback("Aspire");
        throw;
    }
}

For some reason, yet unknown to me, the TransactionRollBack gets called and generates an error:

A transaction with the key [DEF_TRANS_KEY] has not been started.

and this stack trace:

at MicroFour.StrataFrame.Data.DbDataSourceItem.TransactionEnd(String TransactionKey, Boolean IsCommit)
at MicroFour.StrataFrame.Data.DbDataSourceItem.TransactionRollback(String TransactionKey)
at MicroFour.StrataFrame.Business.BusinessLayer.TransactionRollback(String DataSourceKey)
at Aspire.Accounting.Invoicing.UpdateAspireForTransfer()
at Aspire.Accounting.Invoicing.TransferTSB_Click(Object sender, EventArgs e)
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativewindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativewindow.WndProc(Message& m)
at System.Windows.Forms.Nativewindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

So, what am I doing wrong?

Thanks, for straightening me out,
Bill

Does this additional code help?

private void AssignBatchID(String pBatchID)
{
    // attach the batch number to only the selected invoice records
    for (int i = 0; i < invselection.SelectedCount; i++)
    {
        InvoicesCurrentBO mCurrInvoice = (InvoicesCurrentBO)invselection.GetSelectedRow(i);
        InvoiceMasterBO mInvMasterBO = new InvoiceMasterBO();
        mInvMasterBO.FillByPrimaryKey(mCurrInvoice.invoiceindex);
        if (mInvMasterBO.Count > 0)
        {
            mInvMasterBO.Edit();
            mInvMasterBO.batchid = pBatchID;
            mInvMasterBO.Save();
        }
    }
}

I am thinking that the Save() method needs to reflect transactions, like this: mInvMasterBO.Save(true).

If I replace that method parameter whereever a save occurs inside that transaction, will that fix the error?

Bill

I changed all of the save methods to include the true parameter.  Now, I am getting a timeout error.  Does the ReadCommitted IsolationLevel place a lock on any records that were updated, essentially blocking further calls to that record?  Is there another IsolationLevel that I should be using?

Here's a good article describing the different isolation levels that are available for you to use:  http://msdn.microsoft.com/en-us/library/ms173763.aspx

Yes, using ReadCommitted can cause locking issues if you try to read the record again after you have updated it, but before you have committed the transaction.

As for why an exception is being thrown causing the rollback to occur, it is most likely that you need to change your Save() calls on your busines object to call Save(True, "Aspire") so that the business objects are saved on the transaction that you have started.  If you just call Save(True), the business objects will be saved on the "default" transaction, not the "Aspire" transaction.

Thanks, Ben!

ReadCommitted is definitely the safer approach.  I will try to stick with that and work around my transaction issues another way.

Bill

Still not working.

A transaction with the key [DEF_TRANS_KEY] has not been started.

Here is my code:

private void UpdateAspireForTransfer()
{
    try
    {
        // Retrieve the next Batch ID
        String mBatchID = GetNextBatchID();
        AssignBatchID(mBatchID);
        BusinessLayer.TransactionBegin(invoicesCurrentBO1.DataSourceKey, IsolationLevel.ReadCommitted);
        CreateCommissions(mBatchID);
        BusinessLayer.TransactionCommit(invoicesCurrentBO1.DataSourceKey);
        UpdateDynamicsForTransfer(mBatchID);
    }
    catch
    {
        BusinessLayer.TransactionRollback(invoicesCurrentBO1.DataSourceKey);
        throw;
    }
}

The AssignBatchID method assigns a batch ID to the selected invoices.  This was included in the transaction, but I pulled it out and am performing some checks to make sure I am not adding an invalid batch ID.  Then, I fire up a transaction.  It is assigned the DataSourceKey from my InvoicesCurrentBO (which happens to be "Aspire").  The CreateCommissions method simply loops through the invoices selected and adds an entry to the Commissions table, if applicable.  If all is well, the transaction should then commit.  It does not. 

I am thinking that a transaction cannot commit if there are no additions or changes to actually commit.  In the run I am testing there happens to be no commissions assigned, so there are no transactions to commit.  Should I be checking for that first, then committing?  Or, is there something else going on?

Please help,
Bill

I am removing transactions within the code.  This would be a perfect place for them, but I cannot get them to work.

Once I removed them, I ran into another problem which I will address in a separate thread.

Bill

Transactions are a commonly used portion of the framework, but the one thing ab out using trans is environment....so this is one of those things that you may have to supply a sample so that we can see first hnd what is going on.  Sorry

Ok, now that Edhy helped me solve an underlying issue with the primary keys and identity columns, I am going to attempt the use of transactions again.  Since many others are using these successfully, and I am just an average joe , then these should work for me, too.  Their use in the current procedure will go a long way to help me when things get a little messed up.

Ya, I know, it is rare for things to get messed up, but we should always prepare for the remote possibility, eh?

Hangin' in there,
Bill

As I am re-working the transaction thingy, I was wondering, can one transaction cover data changes on two different databases?