Devart Forums

Hi
Reading the release notes, for the latest dotConnect for Oracle release, I observed the following:
* The bugs with memory leak and performance loses when using OCI session pooling are fixed

We currently have the version prior to that, so I assume the issue exists in our build/release.
So which version are known to be affected?
And secondly, what are the details on the memory leak and performances loss. I.e. does it occur regardless of how one uses pooling, and regardless of what type of statements are executed etc.
And if possible could you provide us with some example of how much memory is leaked, i.e. is it 1kb per request or 1000mb per request or whatever - just a ballpark idea would be nice.

The reason for my asking is because we are nearing a release deadline and would like to avoid a last minute third party upgrade - but performance/memory leaks are a cause for concern.

I am well aware, of your "installer issues", I've brought up this case before
I am just hoping that complaining enough will make you prioritise it.

Regarding the test thing, Im pretty sure no amount of stack trace is going to help you because its obviously missing the license information (since my applications hosting project is not the one hosting the integration/unittests, but mstest is).

Ill just have to script a solution for this, so I guess its "okay" for now.

Please consider allowing us to install multiple dotConnect versions side by side. It would immediately fix most of the licensing issues and allow users to maintain "old" code.

Building the license manually works for the hosting application. However my integration tests (run using mstest) still fail me.

I'm guessing I could add the license manually to my test projects, but I have quite a few of those and would prefer not to have to go through that maintenance hell each time we upgrade dotConnect.

Okay, I just tested building a license for the old version with the new one installed and it works.

But again, why oh why isnt this done by the license provider implementation?

The previous version (our latest version in production) is 8.4.379.

I am aware we can build the license manually, but we didn't have to before.

Just to be sure, if we build the license manually, can we be sure we won't have to build a new license once we upgrade (for our old branches that is)?

And second, can I build a license for the old version having only installed the new version? If so - why isn't your licenseprovider doing just that :p

Hi

We recently upgraded to VS 2015, and in order for dotconnect for oracle to work we had to install a new version as well (8.5.521 to be specific).

Previously when upgrading dotConnect we only had to remove the policy files in GAC in order to build and run older versions of our application, because said applications had copies of their respective dotConnect DLL version in the source tree.

For some reason this stopped working with VS 2015 (worked fined with vs2013 and the older dotConnect version). The licensing tool complaints and the the application fails runtime. The only thing that works reliably is to upgrade dotConnect references in our old source (which we would rather not).

Any suggestion on how to get around this?


The license is applied at the hosting application btw (winformsapp.exe) but its a set of class libraries that uses dotConnect.

Hi
Just wondering if you are considering implementing custom varieties of the DbDataReader "whatever"Async methods just as you have with the regular methods, such as ExcuteReaderAsync (returning an Task<OracleDataReader> instead of a Task<DbDataReader>) and OracleDataReader.IsDBNullAsync taking a string as input instead of the ordinal position (etc).

I think you might have misunderstood.
The commit in SqlClient and OracleClient does not CLOSE the connection, but it keeps the connection associated with the transaction such that when you DISPOSE the transaction, the connection is also disposed (and therefore closed).

Of course its been a while since i actually had code using the System.Data.OracleClient and you are right the connection is not disposed when disposing the transaction and the connection is actually disassociated - so I was wrong and my old test were wrong as well.

So just ignore my previous post, sorry for not actually producing a small sample first!

We have an issue with the way dotConnect for oracle removes the connection from a transaction before disposing it (thus it is not closed automatically).

In our code base the connection to the underlying provider is more or less hidden from the developer at all times such that he/she won't have to worry about it.

This includes cases where we need to do multiple things in a transaction.
We have a helper method that looks something like this: Now in the using code we often have something like the following: With the "old" default .NET Oracle and MSSQL Providers this will actually cause the connection to be closed when the scope end (i.e. dispose is called on transaction).
However because the dotConnect provider does something on "Commit" along the lines of: The connection is no longer associated with the transaction once Commit has completed (and thus transaction.dispose won't close the connection).

So basically we now have to remember to do the following all the places we use transactions I know this MIGHT be a design issue, or a breaking change to fix it, but it just seems a bit odd since the behavior is different from the .NET "bundled" providers.

Any chance you are going to change the behavior or will we have to write some sort of analyzer for our code to avoid connection leaks in the future?

Ill give it a try with removing the policy files. Thank you!

Could we get an "advanced" installer option so we can avoid the policy files altogether?

Even though it seems counter intuitive (and probably a big breaking change), you could change to a variety where the assembly version was part of the name. Like Devart.Data.Oracle.8.4.dll for all 8.4.x versions - this is what DevExpress does, allowing them to have side-by-side version while still keep the option of doing bug/security fixes for a specific version.

Anyway just an idea to get around the issue of keep multiple versions at the same time.

Hi

Some time ago we upgraded to Entity Framework 6 and we started to use code based registration of the EF provider.

Everything is fine and working but then we upgraded entity developer and dotConnect for Oracle on our development machines and everything went to hell (upgrade from 8.3.125 to the current 8.4 version).

Now, the developers who have dotConnect installed can ONLY run the newest version of our application. Any attempt to run older vesions (built against older dotConnect assemblies) will give an InvalidOperationException.
This only affects the developers with dotConnect in GAC.
We tried going away from code based registration thinking that this might have changed something, but to no avail.

It seems our only option is to add an assemblyBindingRedirect on our old releases that "downgrades" the assembly to the one we bundle with the application.

The next problem is of course that we have to override the policy because you guys for some reason insist on redirecting to the newest dotConnect version with the installed policy.

To make matters worse we have to redirect all "future" dotConnect releases as well (i.e. specific an invalid high version number in the redirect configuration), otherwise we risk breaking an old version the next time we upgrade dotConnect on the developer machines.

So in short, we have to add configuration clutter to our old releases JUST to make the developers be able to run the application. We could of course add management overhead and have a "developer.config" file for our developers, but unneeded overhead is best avoided!

Any ideas on how to get around this? it seems rather stupid because if we just remove dotconnect from GAC everything is working as intended. Can we get dotconnect nuget releases, or an installation alternative that does not deploy stuff to GAC?

We use quite a few third party developer tools, and while we cannot live without dotConnect it is the only third party tool that causes us such upgrade headaches (this is not the first time we have had multiple version issues like this one).

Hi
We have previously used the performance counters available with System.Data.OracleClient (http://msdn.microsoft.com/en-us/library/ms254503.aspx) to monitor application db performance in "the wild" at customers, back when we used the stock provider.

Now we have changed to dotConnect for Oracle and we need the same thing again. However as far as i can tell there is no such thing for the dotConnect providers (I might be wrong, if so please point me in the right direction).

We can get some of the way by using dbMonitor but is not very pratical to have to sit and monitor output from it, and likewise we need to write tools to parse the data.

If we had performance counters, the gathering could be done in the background and we could use all the existing tools to handle/visualize the data.

Is adding performance counters, on par with the ones in (http://msdn.microsoft.com/en-us/library/ms254503.aspx), on the todo list?

Hi there
We currently use Entity Developer as our "Entity Framework" designer, and we produce database independent code from the model (dbcontext etc).

Currently we support two DBMS types (Oracle and MSSQL) and everything works fine, except for the fact that we have to maintain the actual database scripts in a separate modelling tool.
Entity Developer currently has the option of generating SQL for one DBMS type at a time. Apparently this is determined by the "connection" associated with the model.

It would AWESOME if we could replace our external modelling tool with Entity Developer, but for that to happen we need two things, a way to generate SQL for multiple DBMSes without actually having to change the connection of the model, and a way to generate said SQL scripts from the command line (or an API!).

How this feature is implemented is not that important, it would probably suffice with an option of determining the DBMS to generate SQL for, but "true" multiple relation models (i.e. different type mappings etc) like that which exist in the Oracle SQL Developer Data Modeler tool would be even better since it allows much better control over mappings.

Are any of these features on the roadmap? (i can see CLI support on uservoice has been unchanged since 2011)

Hi
At one of our customers we get a System.AccessViolationException from dotconnect every now and again.

The application is a windows service that regularly pools an e-mail server and inserts/updates some data into a table in the database.

These errors only happens during the night, not every night, but regularly enough that it is becoming an issue. I know you might have no way of reproducing this (I can't either) and it might not even be fixable, but could you look into it? I have included the relevant part of the stack trace.

I think it might be worth noting that the Oracle database is replicated each night, so it is a very likely cause of the problems.