Hi,

I deploy to customer my application. On my developer machine all works fine.. and as always on customer side all goes wrong

The code is simple as on example

      Try

            BusinessLayer.TransactionBegin("PENSOLUTIONOFFICE", lcTransactionKey, Data.IsolationLevel.ReadCommitted)

            mmks_updatePSOForm(loPSOFormStoreBO)



            lSaveResult = loPSOFormStoreBO.Save(True, lcTransactionKey)

            If lSaveResult = MicroFour.StrataFrame.Data.SaveUndoResult.Success Then

                BusinessLayer.TransactionCommit("PENSOLUTIONOFFICE", lcTransactionKey)

                lcErrorMessage = "SUCCESS"

            Else

                Throw New Exception("An error happen during save data!")

            End If

        Catch ex As Exception

            lcErrorMessage = ex.Message

            BusinessLayer.TransactionRollback("PENSOLUTIONOFFICE", lcTransactionKey)

        End Try

On customer machine BusinessLayer.TransactionCommit call an exception (free translation from german) Transaction is finised and can't be used anymore.. something like that...

The question is WHEN transaction is finished? and why on my developer machine all works fine and there an exception happens.

Everywhere installed SQL Server 2008.

Any ideas

Thanks

Denis

I really don't see anything wrong, so at this point is just to try and error unless Trent or somebody else have another suggestion.



Try moving the code mmks_updatePSOForm(loPSOFormStoreBO) before the TransactionBegin...

Edhy Rijo

Please look my last comment.. I thinking I localize the problem untill one line of code

Good, so the problem is here:





As I understand it you are sending your BO as toBO to update some properties. Did you try calling mmks_updatePSOForm() before TransactionBeign...?

Edhy Rijo

Yes.

Even if I leave only one line for update

toBO.filename = Me.PSOForm_filename.Text



TransactionCommit fail in any case..



Yes. I change order of lines and try update befor TransactionBegin.. it does not help...

For this business object I use RowVersionOrTimestampColumn - timestamp

UpdateConcurrencyType - OptimisticTimestamp

This quote is from the "Using Transactional Processing" topic in the SF help file:





Since you are using ReadCommitted Isolation Level and then modifying the BO properties, then the transaction triggers an error. I believe you have two options here:

1-Move mmks_updatePSOForm() before TransactionBeign

2-Change the Isolation Level to ReadUncommitted



Also check this KB: http://msdn.microsoft.com/en-us/library/ms173763.aspx



Try boths and let me know.

Edhy Rijo

I made so

mmks_updatePSOForm(loPSOFormStoreBO)

BusinessLayer.TransactionBegin("PENSOLUTIONOFFICE", lcTransactionKey, Data.IsolationLevel.ReadUncommitted)



and have no success.. same error.. about transaction end and can't be used..



I give up for today.. now is 01:19 am in Moscow Maybe morning bring something

Thanks for your help!

See ya!

Denis

This is error message details..

Transaction still does not work. I had restart a SQL Server.

What is ZombieCheck is?

Just idea

Maybe the code close the connection without completing the Transact-SQL transaction.

So.. I use business object in separate dll and transactionBegin and TransactionCommit in aspx file. Is there on BO.Save() connection is closed? and then.. Transaction is no more control a connection.. or?

Or I request another connection and receive the previous connection from the connection pool.. so its seems also possible...



Please any ideas

And the last idea what I have...

When I made BO.SAVE() - because BO has timestamp - then after changes commited, BusinessObject make FILL to refresh new timestamp.. and FILL close connection.. and - seems then TransactionCommit has no more mind - because connection is closed.

Of couse I use BO.SAVE(true, lcTransactionKey) - and on my developer machine I have not a problem.. - this is strange... but diffrence only.. all my business objects stored in separate DLL.. and from aspx I just reference this dll.. createobject.. and so on..

TransactionBegin - running in aspx... BO.SAVE() occurs in DLL... TransactionCommit() also in the aspx...



So.. I realy need help ... don't know what to do

OK, let's back up several steps and talk a little logic and maybe we can work through this.



First of all, a ZombieCheck is a piece of an SQL Transaction looking for a stale (or closed) transaction. This is intrinsic to the Sql Client, and is correct in checking. But another thing that I would like to revisit here, as there was a lot of chatter, but the thing that struck me was this: when you copied over the MDF from your development machine, it worked.



Put all of the code aside. If your code was left intact and you ran this against two different databases and it worked on the one created in your development server (MDF) and the same code failed when run against the production server, then there is most definitely a SQL side issue.



Please confirm that what I have said is accurate before I go down another path. Thanks.

Hi Trent,

Thanks for response.

1) I shutdown developer SQL Server 2008 - and copy MDF file and upload to customer by FTP

2) Download MDF file and copy it to the Programme\Microsoft SQL Server\ MSSQL10.MSSQLSERVER\MSSQL\DATA on customer side

3) Attach database to customer SQL Server 2008

4) On Developer SQL Server - no problem. All works as expect

5) On customer side problems begins with Error message

A transaction with the key [PENSOLUTIONOFFICE] is already started. (at this time I used same name for all transactions.. and I thought during my code one transaction begins and not finished with rollback or commit.. probably crush or cancel debugging

6) Then I change my code and began generate unique GUID string as key for all new transactions.

7) Then I have error message about transaction is closed and can't be used.

8) Then I made for test changes.. fill business object by primary, change nothing .. Save() Commit() - all works

9) Then I change one field of BO and try Save().. Commit() - and then error happens again.



So this is what I have now.

Well, you might be chasing your tail (I have been known to do that from time to time ). We store off a cache of transaction keys, so it is actually NOT recommended to use the same transaction key for different processes that could be going on at the same time. For example, if I am going to save 2 BOs on the same transaction during the same process, that is fine as I would want to use the same transaction key. However, if there is potential for there to be two separate process try to start a transaction on the same key at the same time, it will fail. So procedure could be the difference at run-time versus design-time.



One thing I might suggest is creating a sample for you to work off of that is simple so you can isolate the issue. For example, create a single table (or two if that is what your test requires) on a test database. Then create a new project, one (or two) BOs, then create a single button that creates the transaction, creates the records, and saves. If this works in both environments, then you will know exactly where your issue resides. I generally take this type of approach on errors like this so I can isolate the issue. Once isolated, it is far easier to see what is going on within the application at large.

Hi,

All good what you say but then I need a StrataFrame license on cusomer side.. to buid such examples. On developer machine I have no problems without any examples.

I am currently remove all transactions from my code.. because I have realy a stress by my work.. its shortest solution already work.. and maybe in future.. I will add transactions again when I understand whats wrong.. and will have more time to play instead work.



Thanks for attention

Denis

Hi Denis,



Trent was not suggesting you build a sample at the customer site. What I understand from his previous message is that it would be good to build another test project with just 2 tables and 2 BO so you can test on an easy to reproduce project to help you find what the issue is.



I use transactions all the time using basically the same code as yours, except that I do not make any changes to the BO properties after the transaction begins and so far have not found any problems, but that does not mean that you have a real issue here.

Edhy Rijo

Sorry this should have read:

Edhy Rijo

What Edhy mentioned is exactly what I was getting at. There is no reason to do this on the customers site. I am suggesting that you build a simple EXE that you can run and test against. This is how I isolate problems within my code as well.