Awesome, thanks!
Ryan
Search found 6 matches
- Wed 06 May 2009 17:45
- Forum: dotConnect for MySQL
- Topic: dotConnect support for Mono 2.0
- Replies: 2
- Views: 1765
- Wed 06 May 2009 17:45
- Forum: dotConnect for Oracle
- Topic: any SQL levelling features across the providers?
- Replies: 3
- Views: 1842
- Tue 05 May 2009 18:15
- Forum: dotConnect for MySQL
- Topic: dotConnect support for Mono 2.0
- Replies: 2
- Views: 1765
dotConnect support for Mono 2.0
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
If so, what platforms was the Mono testing conducted? Linux? OSX? Windows?
Thanks,
Ryan
- Tue 05 May 2009 18:12
- Forum: dotConnect for Oracle
- Topic: any SQL levelling features across the providers?
- Replies: 3
- Views: 1842
any SQL levelling features across the providers?
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
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
- Tue 05 May 2009 18:04
- Forum: dotConnect Universal
- Topic: cross-database support: performance vs. dev effort
- Replies: 3
- Views: 4072
- Thu 30 Apr 2009 23:47
- Forum: dotConnect Universal
- Topic: cross-database support: performance vs. dev effort
- Replies: 3
- Views: 4072
cross-database support: performance vs. dev effort
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
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