Bye bye SQL Server OLE DB, welcome back ODBC
-
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[^]
-
Bloody hell, once again they shoot themselves in the foot with poor communications. Why can't they release information properly any more? It's a recurring theme lately with them.
There is no failure only feedback
-
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
Amen! ADO was easier to use (with C++) than was ODBC. When ADO came out, I burned by old ODBC books in the campfire. Good riddance.
-
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...
Well, see, the .NET framework has a lot of really well-tuned functions. So well-tuned, in fact, that it's nearly impossible to beat their performance. Not all of them are that well done, but some are! What actually winds up happening is that your code gets recompiled into mostly native code at runtime by the interpreter. You do wind up with some native code in the end. So, it's not exactly apples and oranges when you compare the two. There are a lot of abstractions and layers involved. You could do a lot worse yourself, if you don't have the experience to figure out how much abstraction is too much. Sure, you could hand-tune things, but you have to figure the cost-benefit ratio when you're on a deadline. Mission-critical software that has to have perfect timing and zero excess code might need that hand-built assembly. A simple GUI for a database query tool doesn't need it. You could even consider the .NET stuff as a sort of intermediate mock-up, so you could "just make it work" for your manager/demo if you have to, then replace the slow parts later... Whatever you need to do to make your paycheck. That's what profilers are great for - determining if you have a bottleneck that you could address by writing hand-made code.