I am writing an class using C++ (ATL).. I need to connect to a database. I am familiar with ADO but I see that all the functions are using IDispatch (late-binding/Automation). I am considering using OLEDB instead. What are the pros and cons of each? OLEDB seems like a lot of maintenance if the sql changes (tables, stored procs, etc). I did use the wizard to create some OLEDB headers and they dont seem as easy to "use" as ADO but speed does count. ADO also has an easy mechanism to convert the result to XML as well which is something I need. has any one used both before? which did you prefer? thanks!
to clarify, i am mentioning ATL only because there are ATL wizards for creating OLEDB consumer objects helps.
Using the ATL classes that wrap OLEDB is the way to go. If you consider that you're going to have to map your database schema to internal C++ classes regardless, then you're going to either do it with ADO and lots of painful IDispatch or with OLEDB which is a more natural in C++. If your database schema changes, you're going to have to modify your code regardless of the approach.
ADO is an OLE Automation wrapping of OLEDB, so the will not be any performance gains except that you'll have a lot less IDispatch thunking code to write.
There are many choices and approaches to getting that data into an XML form.
Related
I will have a Postgres database in production but want to use MS SQL (whatever edition) for reporting. So, I would like to have replication set up where MS SQL subscribes from postgres. Is this possible?
All heterogeneous replication scenarios are deprecated by Microsoft, and they now recommend building solutions using SSIS and CDC instead.
We load data from PostgreSQL into our SQL Server reporting database using SSIS and it works well, although we had to use a commercial OLE DB provider because of limitations (at that time) in the open-source one.
Actually copying the data is usually the easy part; most of the work comes in gathering requirements, understanding the data, transforming it, implementing logging and error handling etc. SSIS can do some things for you right away (e.g. logging) but my general advice would be to use it primarily as a workflow tool and for simple data copying with minimal transformation logic (e.g. data type conversion). If something seems seems too difficult or clumsy in SSIS then you can put it into a stored procedure or script and call that from SSIS instead.
I've been using and following PostgreSQL for several years and not aware of such a solution. If one exists, I'm concerned that might be complex or fragile. I would recommend regular export/imports via cron. In the between the export and import, you would need to take care of the translation step of the formats.
If you reporting actually happens in MS Excel or MS Access, I recommend looking into connecting them directly to PostgreSQL via ODBC.
I don't know between ADO, DAO and DLookUps and such. Does anyone know?
I find that the application bottleneck is usually the actual SELECT/INSERT/UPDATE on the DB and not how the application calls it. if you are worrying about speed make sure you have well designed tables and indexes.
Regarding DAO vs ADO, I'm not sure about a difference in performance but there is a difference in available functionality.
There is a microsoft article showing the differences in a nice table. Choosing ADO or DAO.
It also states:
"In particular, ADO is a good choice if you are developing an Access database solution that will later be upgraded to SQL Server — you can write your ADO code to minimize the number of changes that will be required to work against a SQL Server database. In addition, ADO is a good choice for developing new data access components that work with SQL Server, multidimensional data, and Web applications."
Seems like ADO might be the way to go.
I don't know anything about DLookUps though.
I'm looking for suggestions as well as any benchmarks or observations people have. We are looking to rewrite our data access layer and are trying to decide between native C++ OLEDB or ADO.NET for connecting with databases. Currently we are specifically targeting Oracle which would mean we would use the Oracle OLE DB provider and the ODP.NET.
Requirements:
1. All applications will be in managed code so using native C++ OLEDB would require C++/CLI to work (no PInvoke way to slow).
2. Application must work with multiple databases in the future, currently just targeting Oracle specifically.
Question:
1. Would it be more performant to use ADO.NET to accomplish this or use native C++ OLE DB wrapped in a Managed C++ interface for managed code to access?
Any ideas, or help or places to look on the web would be greatly appreciated.
I don’t think it is possible to give a single answer that is generally applicable in this situation considering the fact that you are wanting a general solution for more than just Oracle. The problem is that one vendor’s .NET provider might be faster than their OLE DB provider and vice versa for another vendor. The architecture of both of those data access technologies is significantly different.
My gut feel is that the speed differences would not be that great, though. Since it sounds like you would put your own data access layer on top of OLE DB, it is hard compare directly until you wrote that. But in general, any data modification statement (e.g., UPDATE mytable set…) probably is not going to be all that different in either case. With both technologies, you specify parameter data if appropriate and then send the command to the server. The bulk of the cost is likely going to be network latency and server execution times. The biggest difference would probably come into play when reading data sets.
Reading the data is going to be the factor that could show a difference in speed. Depending on what you are planning, you may want to read the data at a low level. For example, with OLE DB, you may call IRowset::GetNextRows. With .NET, you would maybe read through the data sets via DbDataReader::Read(). I don’t know if it is typical, but in the code I worked on, the OLE DB GetNextRows() method was much more complex than the .NET Read() implementation. I am not sure if that necessarily translates to slower execution … but it might.
In my opinion, the best choice would be to use ADO.NET. Since it is Microsoft's current data access technology, I suspect that vendors will update their .NET provider more often than their OLE DB provider. So if there are performance problems in implementation, the .NET provider is likely going to be fixed while their OLE DB provider may not be fixed as promptly (or at all). Also, you get a lot more flexibility with the .NET provider if you need it (e.g., entity framework). If you want that with OLE DB, you are going to need to use the .NET provider for OLE DB providers, which is another layer on top of OLE DB (assuming it would even work, which I do not know).
I found this question here: OLEDB v/s ODBC
Which gave me more information, but did not really answer the question I'm asking, so I shall proceed from there.
I am working in C#. I'll spare you the long story about how I arrived at this conundrum, but basically I'm trying to decide between ODBC and oleDB.
We work with a lot of different clients who have vastly varied Databases (some SQL, some oracle, some something else that I've never heard of and didn't bother to remember the name of)
Now, from what I understand, ODBC is old, and was/is the standard. And now OleDB has come along and... is... different? but accomplishes the same thing (it talks to databases)
Why would I want to use one over the other? ODBC is (according to the above post) cross-platform, which is good, but he offers very little information as to what OleDB offers that ODBC does not.
In my other research, I've found (on the MSDN forums) People saying "use OleDB if you can, if you have to, resort to ODBC" Naturally, three's no reasoning given for this, so I'd like to hear some.
ODBC is a C API for accessing databases. There is a standard for it, it is supported by every major database vendor, it is very well documented, it is cross-platform. OLEDB is a similar interface that uses Microsoft's COM technology instead of the C API. This means that it is only easily useable on platforms that support COM.
At the end of the day, both libraries provide roughly equivalent basic functionality. Indeed, Some OLEDB drivers actually make use of ODBC rather than native database libraries.
So, if you are C# developer, working on Windows, OLEDB is the obvious choice between the two. If you are using C (or C++ not using COM), or need cross-platform support, then ODBC is the better bet.
As a C# developer and because you are accessing many different datasources you should go with OLEDB. I copied the following from this white paper because it gives some hints what to use when:
OLE DB is Not a Replacement for ODBC
The ODBC technology and third-party market have matured to a point at which ODBC is an ideal technology for accessing SQL databases. As a result, an integral part of OLE DB is a new OLE DB driver manager that enables OLE DB consumers to talk to ODBC providers. The following information can guide your choice of which technology to use:
If you are accessing standard relational databases from a non-OLE environment, ODBC is the best choice.
If you want to expose a data interface to non-SQL data, OLE DB is the best choice.
If you are programming in an OLE environment, OLE DB is the best choice.
If want to build interoperable database components, OLE DB is the only choice.
If you're programming in C#, you will not directly use either one. You'll use ADO.NET in some form.
True, the provider that you specify in your connection string may turn out to be an ODBC provider or an OleDB provider, but this will not matter to your code. ADO.NET will both APIs from your view.
I'm developing an asp.net application with Database factory pattern which allows the application to support both Sql Server and Oracle. I've created an abstract class that has the methods common to Sql Server and Oracle, like the CreateConnection and CreateCommand methods. This class is implemented by SqlServer and Oracle classes. Now, is there an easy way to write in-line sql queries with parameters common to both Sql Server and Oracle. I mean, I understand that we use "#" symbol in Sql Server and ":" in Oracle for parameters. Just for this reason, I'm writing queries twice in each of the class. Is there a way to write such queries common to both the databases? (or interpret the parameters from one common query?)
Thanks.
The only way to write one query that will work for both Oracle and Sql Server is to use only the syntax that is common to both platforms. Once you use features that are different between the two languages (like parameters or joins), you either have to write two different queries or hack together a "translator" class that converts a query from one platform to the other.
I've done a lot of this type of programming (database-agnostic software), and with .Net a relatively pain-free way of doing this is to write your main application to work entirely with ADO.Net DataTables/DataSets, with a wrapper class that handles generating the DataTables from either Oracle or Sql Server tables under-the-hood, and also handles persisting changes made to the DataTables back into Oracle or Sql Server. This approach isolates your DB-specific code in one place, although it's not necessarily a viable approach if the data your application needs access to is large.
You could write some kind of translator, but I would suggest that in some cases you'll need to write db-specific code for performance reasons anyway, so you'll have to put up with the maintenance burden of two versions of some queries.
What is the point of using ORACLE and not using all its non standard functions (analytics, pivots etc) ? ORACLE is a powerful tool.
Other DBs have there own strenght also, so why use the lowest common denominator just to be able to work on ALL of them? You will just lose in performance.
Just pick one DB, and use it fully with all its functionalities !
Pardon my ignorance here, but can't something like an ORM (object relational mapper) work for both SQL and Oracle?
I had similar requirements, to support both Sql Server and Oracle, and summarized my two years of experience with such problems in these articles:
Writing ANSI Standard SQL is not practical.
Think ANSI Standard SQL Is Fully Portable Between Databases? Think Again.