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.

Sorry this should have read:

Edhy Rijo

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

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

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 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.

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.

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

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

This is error message details..

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

What is ZombieCheck is?