Hi

I ran into a problem concerning keeping an Oracle connection open. I create a DataAccessAdapter object, setting the KeepConnectionOpen property to be true. I then perform many save actions in the following way:

StartTransaction SaveEntity UpdateEntitiesDirectly . . . Commit; . . ExecuteActionQuery . . SaveEntity . . GetScalar . . StartTransaction SaveEntity UpdateEntitiesDirectly . . . Commit; . . ExecuteActionQuery . .

For several months it has been working fine - the connection was always open, as expected, but lately I've made a change - I started using ODP directly (with the same connection that the adapter uses, got it by GetActiveConnection) - OracleCommand.ExecuteNonQuery instead of ExecuteActionQuery. So eventually in my heavy scenario I use the adapter's connection not only for adapter's actions, but also for actions that cannot be performed by the adapter (DDL), and I don't see a problem with that.

Anyhow, since the change, actions like GetScalar closes the connection, as the KeepConnectionOpen property changes to false a little before, and an exception is raised when trying to perform the first action comes right after GetScalar.

I can't see how the change I've made causes the problem, I'll appreciate any help.

What's the runtimeLibrary version that you are using? (right click on the "SD.LLBLGen.Pro.ORMSupportClasses.NETxx.dll" file select Properties, then go to the version tab, and there you will find the "File Version" attribute)

I'm using 1.0.20042.(0)50605

Please try with the latest 1.0.2004.2 builds (build 1.0.20042.51110)

So what I've described is actually a known bug in the version I use? Nothing I did was wrong?

This may be the cause of your behavior. This is from the changelog available here http://www.llblgen.com/pages/secure/ChangeLogBrowser.aspx

Runtime Libraries 1.0.2004.2 ORM Support Classes, DQEs 1.0.2004.2 09192005 19-sep-2005

DataAccessAdapter.Commit() calls internally Reset(), which clears the KeepConnectionOpen flag, while it shouldn't reset that flag.

orenpeled wrote:

So what I've described is actually a known bug in the version I use? Nothing I did was wrong?

If I ask you to use the latest version to see if that fixes your problem, please do so. Also please consult the changelog viewer which allows you to search for bugfixes, see Brian's post above.

OK

Brian, the link you suggest leads to nowhere.

You also mentioned that the DataAccessAdapter.Commit() method causes the problem, but as I described in my first message, I've been using this method for a long time and no problem came up. Only since I started using the adapter's connection to initialize an OracleCommand object (and calling ExecuteNonQuery instead of ExecuteActionQuery), without changing the actions or their order, a problem came up.

Did the latest version (build 1.0.20042.51110) solve your problem?

The link posted by brian had a '.' at the end, the parser included that in the URL. I've removed it. it should work now (you can also reach it from the left menu in the customer area)

I think the problem was partially solved. I use version 1.0.20042.51110, but now calling SaveEntity causes a problem (before changing version it failed in an earlier call to GetScalar). Anyhow, after calling SaveEntity, the KeepConnectionOpen remains true, but the connection is closed.

Ok, so there's still an issue with the code? I'll have a look and if I'll find a bug, I'll fix it for you in the 1.0.2004.2 codebase. (though if possible, upgrade to 1.0.2005.1)

I can't find a call to CloseConnection() which isn't protected with a check to KeepConnectionOpen. Also, if the connection is closed in CloseConnection(), KeepConnectionOpen is set to false. As it's true, the connection must be closed somewhere in the code you call yourself, which uses the connection.

I figured it out. If any query performed by DataAccessAdapter causes the connection to be closed, a second query, again with DataAccessAdapter, reopens the connection and everything is fine. But if I try to perform the second query with OracleCommand.ExecuteNonQuery and not with DataAccessAdapter - no reason for the connection to reopen, and an exception is raised.

Glad it's solved