Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Bullets from the <a href="http://www.youtube.com/watch?feature=player_embedded&amp;v=I1q50HnUh_w">quick start video</a>:</p> <ul> <li>Fewer files (1 or 2 dlls at most)</li> <li>Smaller footprint (10 MB compared to 200 MB)</li> <li>Easier side by side deployment</li> <li>Same assembly for 32 and 64 bit (except for second MTS assembly).</li> <li>Code Access Security</li> </ul> <p>I'm not sure about performance but I doubt it will be much different either way. My guess is that the two drivers communicate in an identical way over "Oracle Net." While there might be minor differences in the in-memory client side operations done to prepare a command and process the results, this overhead typically only represents a fraction of the time relative to the entire transaction. Most of the cost/time is spent on the server in physical IO and transferring the data back to the client. This simply isn't the same as going from the oledb provider or the System.DataAccess.OracleClient driver. This is another release from the same RDBMS company - they're going to exploit all the same performance tricks that their other client used. I wish I could post a study, but i'd guess such a thing doesn't exist because in the end it would be unremarkable. A case of no news is good news - if the new provider was somehow worse you would be reading about it.</p> <p>Simplicity is enough reason to switch to this IMO. The vast majority of developers and administrators do not fully understand the provider and its relationship to the unmanaged client. Confusion about oracle home preference, version mismatch, upgrades, etc comes up constantly. To eliminate these questions would be a welcome change.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload