Devart Forums

Awesome, thanks!

Ryan

I did check it out, but UniDirect.Net isn't up to date with the latest dotConnect providers. Any eta on this?

Thanks,
Ryan

Do the latest versions of the dotConnect providers support, and have been tested and validated against, Mono 2.0 as well as .Net?

If so, what platforms was the Mono testing conducted? Linux? OSX? Windows?

Thanks,
Ryan

One of your competitors DataDirect provides roughly a half-dozen interoperability features of their support providers, such as ODBC escapes, parameter markers, consistent ErrorCollection impl, error code mapping, Oracle ref cursors, and arrays of parameters. For more info you can read this:

http://www.datadirect.com/developer/net ... bility.pdf

There is also a good bit of SQL up-levelling going on:

http://www.datadirect.com/developer/doc ... veling.pdf

Several of these make cross-vendor ADO.Net code much cleaner and easier to write and maintain, in particular the escapes, markers, and error enhancements.

Which if any of these are implemented across the dotConnect suite?

Thanks,
Ryan

Andrey, thank you for your response, it was very helpful.

Edit: Do you have an ETA for UniDirect update to use latest dotConnect providers?

Thanks - Ryan

These aren't really UniDirect questions per se, but it's related, so this seems to be the best forum. I have a ton of cross-database platform related questions...

I'm building a quite large enterprise product (in C#) that will require using a customer provided provided database license on 3 databases (potentially 3 different servers), and need to support:

Oracle
SQL Server
MySQL
Postgres
DB2

I want to build my database layer to be as portable as possible to reduce development effort and maintenance costs. However, this time savings can not trump performance. One of the datastores in particular needs absolutely best possible performance.

I'm leaning against UniDirect for several reasons:

- there appears to be no version that supports latest dotConnect providers
- there appears to be no new version recently at all (11 months)
- there are a lot of posts complaining about performance

From a performance standpoint, is it indeed true that I would be better off using the various dotConnect providers as well?

Is it true that in order to maximize cross-platform portability, I'll be best off avoiding any "customizations" in the pro versions of the various dotConnect products, and in fact if I stick with core System.Data base abstract classes and interfaces, things will in general be much more portable?

Is there a performance difference between dotConnect for SQL Server and dotConnect for Oracle vs. what MS provides natively in the .Net Framework, for the *standard* features? If so which performs better, and under what scenarios?

Using the EF is going to clearly save me time, and I believe it will also increase portability. However, I am concerned about the performance overhead. Can anybody share their experiences here? It may be that for a few of our data stores for fringe functionality we use EF, but for the core datastore that has to scream we use ADO.net providers directly.

I'm still not 100% sold that ODBC wouldn't be my best route. For each of the database vendors listed above, is it indeed true that going with the dotConnect provider will always provide superior performance over using the System.Data.Odbc and just relying on the underlying vendor-provided Odbc diver? Most ADO.Net articles I've read show that it is usually faster than ODBC, but these invariably compare SQL Server only. They also use the "stock" ODBC drivers, and not wire-protocol drivers from 3rd party vendors which have significantly better performance and scalability.

Why is there no DB2 dotConnect product? Am I missing something?!?

Finally, are any/all dotConnect provider implementations "wire protocol" implementations, or do they go throught he client libraries provided by the particular database vendor?

Thanks in advance for answering these questions...

- Rhino