Bye bye SQL Server OLE DB, welcome back ODBC
-
What! WHAT! are you nuts... oh the only api supported on all platforms, thats allright I don't build for ALL platforms so you can take ODBC and shove it back into the 90s where it belongs.
Never underestimate the power of human stupidity RAH
-
What! WHAT! are you nuts... oh the only api supported on all platforms, thats allright I don't build for ALL platforms so you can take ODBC and shove it back into the 90s where it belongs.
Never underestimate the power of human stupidity RAH
As a vertan I can assure you that OLE DB sucks. It is not an "ready to use" API. It attempts to be an abstraction layer for different API's to build a usable API on top, but with all the "may or may not be implemented by the provider" it's no better than an exercise in Joel's Leaky Abstractions[^] concept. The only advantage is that when moving to another database, you are programming against the same API - but your client code will still subtly differ. The general architecture isn't half bad and would probably even be able to carry its promise of covering "everything databasey". But with the very verbose code and the weird mix of raw pointer manipulation, COM and C-style resource management, provider implementations do what's necessary to work, no more. Still, I'm surprised that we are back at ODBC.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx[^]
The need to optimize rises from a bad design.My articles[^]
This is precisely why I don't take Microsoft seriously when they come out with a new framework, API or interface library which is suppose to make my life easier. It never does, and then I have to go in and fix others' code who got caught up in the hype.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
Honesty is the best policy, but insanity is a better defense. -- Steve Landesberg
-
This is precisely why I don't take Microsoft seriously when they come out with a new framework, API or interface library which is suppose to make my life easier. It never does, and then I have to go in and fix others' code who got caught up in the hype.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
Honesty is the best policy, but insanity is a better defense. -- Steve Landesberg
Michael Bergman wrote:
when they come out with a new framework, API or interface library
I agree, I dislike the .NET framework also. Sure, it wouldn't be as bad if it was literally just a collection of libraries, but why do they need to go to the extent of making all .NET programs run in a VM? Just seems like they want everything to run slow.
See if you can crack this: b749f6c269a746243debc6488046e33f
So far, no one seems to have cracked this!The unofficial awesome history of Code Project's Bob! "People demand freedom of speech to make up for the freedom of thought which they avoid."
-
Michael Bergman wrote:
when they come out with a new framework, API or interface library
I agree, I dislike the .NET framework also. Sure, it wouldn't be as bad if it was literally just a collection of libraries, but why do they need to go to the extent of making all .NET programs run in a VM? Just seems like they want everything to run slow.
See if you can crack this: b749f6c269a746243debc6488046e33f
So far, no one seems to have cracked this!The unofficial awesome history of Code Project's Bob! "People demand freedom of speech to make up for the freedom of thought which they avoid."
Lloyd Atkinson wrote:
why do they need to go to the extent of making all .NET programs run in a VM? Just seems like they want everything to run slow
That's the classic complaint from native-mode developers who've never done any .NET programming. I ought to know; I was one of them. .NET applications can be as fast (or faster) than native applications, depending on the circumstances. I've found that the 'speed' of an application depends far more on the programmer's competence than it does the underlying environment.
Software Zen:
delete this; -
Lloyd Atkinson wrote:
why do they need to go to the extent of making all .NET programs run in a VM? Just seems like they want everything to run slow
That's the classic complaint from native-mode developers who've never done any .NET programming. I ought to know; I was one of them. .NET applications can be as fast (or faster) than native applications, depending on the circumstances. I've found that the 'speed' of an application depends far more on the programmer's competence than it does the underlying environment.
Software Zen:
delete this;Gary Wheeler wrote:
NET applications can be as fast (or faster) than native applications, depending on the circumstances.
I've found that the 'speed' of an application depends far more on the programmer's competence than it does the underlying environment.No. .Net code running in a VM *cannot* be as fast as native code. This is just impossible. But *your* native code can be slower than *your* .Net code if you're a bad developper. Microsoft knows that .Net is too slow and bloated: WPF, Silverlight are dying. In Windows 8, .Net Framework has been replaced by WinRT. What is funny about WinRT is that it is based on COM. COM is another 90s technology...
-
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx[^]
The need to optimize rises from a bad design.My articles[^]
I'm currently working on migrating data from (Unix) Informix SQL server to MS SQL an guess what - ODBC rules. I'm using a wonderful tool: WinSQL to tinker with the Informix SQL server using ODBC. It's not as bad as one would think. All the crap software that IBM offers for the Informix server simply did not work - so I had no choice but to use ODBC. It gets the job done - and that all I need right now.
-
I'm currently working on migrating data from (Unix) Informix SQL server to MS SQL an guess what - ODBC rules. I'm using a wonderful tool: WinSQL to tinker with the Informix SQL server using ODBC. It's not as bad as one would think. All the crap software that IBM offers for the Informix server simply did not work - so I had no choice but to use ODBC. It gets the job done - and that all I need right now.
When doing cross platform operations, ODBC is just fine. However I'm a bit dissapointed on MS since OLEDB was supposed to 'replace' ODBC and lots of people have invested/written software for OLEDB. Now this is going to be taken away...
The need to optimize rises from a bad design.My articles[^]
-
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx[^]
The need to optimize rises from a bad design.My articles[^]
I'm writting this C++ application that will synchronize some data between SQL Server and SharePoint, and -oh the irony- it was going to be my first app using OLE DB... oh well, back to good ol' CRecordset I guess...
-
I'm writting this C++ application that will synchronize some data between SQL Server and SharePoint, and -oh the irony- it was going to be my first app using OLE DB... oh well, back to good ol' CRecordset I guess...
-
Gary Wheeler wrote:
NET applications can be as fast (or faster) than native applications, depending on the circumstances.
I've found that the 'speed' of an application depends far more on the programmer's competence than it does the underlying environment.No. .Net code running in a VM *cannot* be as fast as native code. This is just impossible. But *your* native code can be slower than *your* .Net code if you're a bad developper. Microsoft knows that .Net is too slow and bloated: WPF, Silverlight are dying. In Windows 8, .Net Framework has been replaced by WinRT. What is funny about WinRT is that it is based on COM. COM is another 90s technology...
pmorelfourrier wrote:
No. .Net code running in a VM *cannot* be as fast as native code. This is just impossible.
But *your* native code can be slower than *your* .Net code if you're a bad developper.A good developer is the one who delivers good software on time. Not the one who delivers excelent software too late... (someone said it) Yes, it's true .NET isn't as fast as Native, but it has a lot of work done in optimized classes that you would have a lot of work implementing in Native code.
pmorelfourrier wrote:
What is funny about WinRT is that it is based on COM.
COM is another 90s technology...X|
Paulo Gomes Over and Out :D
-
I'm writting this C++ application that will synchronize some data between SQL Server and SharePoint, and -oh the irony- it was going to be my first app using OLE DB... oh well, back to good ol' CRecordset I guess...
How are you communicating with the SharePoint server from C++? Just curious... I might like to do that in the future.
-
Lloyd Atkinson wrote:
why do they need to go to the extent of making all .NET programs run in a VM? Just seems like they want everything to run slow
That's the classic complaint from native-mode developers who've never done any .NET programming. I ought to know; I was one of them. .NET applications can be as fast (or faster) than native applications, depending on the circumstances. I've found that the 'speed' of an application depends far more on the programmer's competence than it does the underlying environment.
Software Zen:
delete this;I have done a bit of .Net programming, but I write code for other systems/operating systems, and I often have to count cycles, particulary for embedded systems I work on, so this is probably why I have that view of .Net :P
See if you can crack this: b749f6c269a746243debc6488046e33f
So far, no one seems to have cracked this!The unofficial awesome history of Code Project's Bob! "People demand freedom of speech to make up for the freedom of thought which they avoid."
-
What! WHAT! are you nuts... oh the only api supported on all platforms, thats allright I don't build for ALL platforms so you can take ODBC and shove it back into the 90s where it belongs.
Never underestimate the power of human stupidity RAH
COM is so 1990s....
-
I have done a bit of .Net programming, but I write code for other systems/operating systems, and I often have to count cycles, particulary for embedded systems I work on, so this is probably why I have that view of .Net :P
See if you can crack this: b749f6c269a746243debc6488046e33f
So far, no one seems to have cracked this!The unofficial awesome history of Code Project's Bob! "People demand freedom of speech to make up for the freedom of thought which they avoid."
Lloyd Atkinson wrote:
particulary for embedded systems I work on
Yup, no surprise there. I've done my share of PIC programming (not to mention old-school 8-bit stuff like 8085's and Z-80's, once upon a time). I was simply arguing against the generalization, which I had expressed myself at one time.
Software Zen:
delete this; -
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx[^]
The need to optimize rises from a bad design.My articles[^]
-
How are you communicating with the SharePoint server from C++? Just curious... I might like to do that in the future.
By using SP2010 REST APIs and SP2010 web services (those located at /_vti_bin/ directory), a little help from the WWS API and good ol' MSXML... BTW, one of our research projects -that I'll be leading next March- will consume SP information from an iOS device... we'll be using the same approach, only without WWS and MSXML... let's see how it turns out... Cheers!
-
As a vertan I can assure you that OLE DB sucks. It is not an "ready to use" API. It attempts to be an abstraction layer for different API's to build a usable API on top, but with all the "may or may not be implemented by the provider" it's no better than an exercise in Joel's Leaky Abstractions[^] concept. The only advantage is that when moving to another database, you are programming against the same API - but your client code will still subtly differ. The general architecture isn't half bad and would probably even be able to carry its promise of covering "everything databasey". But with the very verbose code and the weird mix of raw pointer manipulation, COM and C-style resource management, provider implementations do what's necessary to work, no more. Still, I'm surprised that we are back at ODBC.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchypeterchen wrote:
The only advantage is that when moving to another database, you are programming against the same API - but your client code will still subtly differ.
Attempting to generalize complex APIs to target replaceable plugins is difficult at best. And in terms of databases I doubt it is possible to build a generalized API that doesn't require tweaking for different databases. Java Hibernate makes a pretty good try but that is based on creating an abstraction layer even for SQL itself, and even then there will likely be differences for larger systems. Not to mention that database moves are extremely rare in programming. Businesses either stick with one or target many. For the former if a database migration is required then it is an enterprise level risk that requires large scale testing regardless. For the latter if a businesses that test many from the start will quickly understand the differences. Businesses that don't will see their failure in time.
-
Gary Wheeler wrote:
NET applications can be as fast (or faster) than native applications, depending on the circumstances.
I've found that the 'speed' of an application depends far more on the programmer's competence than it does the underlying environment.No. .Net code running in a VM *cannot* be as fast as native code. This is just impossible. But *your* native code can be slower than *your* .Net code if you're a bad developper. Microsoft knows that .Net is too slow and bloated: WPF, Silverlight are dying. In Windows 8, .Net Framework has been replaced by WinRT. What is funny about WinRT is that it is based on COM. COM is another 90s technology...
pmorelfourrier wrote:
No. .Net code running in a VM *cannot* be as fast as native code. This is just impossible.
But *your* native code can be slower than *your* .Net code if you're a bad developper.Given the vast number of apis, the vast number of business domains, the vast number of programming idioms, the vast number of ways of learning about each (of which many are often wrong or at best just average).... *Most* developers will never have the knowledge necessary to make an *average* business application as fast as possible *regardless* of the language chosen. And of course this even presumes that a positive performance gain for some aspect is even relevant to the business itself. That is also something developers might nor might not learn over time. Nothing is more irritating to find that a developer has spent 3 days 'optimizing' a piece of code to run 10% faster yet it has no significant performance gain on any actual business functionality.
-
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx[^]
The need to optimize rises from a bad design.My articles[^]