I reviewed different means for connecting to oracle db from Haskell. I found one, ODBC. Ideally, I wish to use an oracle client to connect. Do you know any other way?
Thank you.
Takusen provides direct access to Oracle DBs, however, the ODBC-enabled libraries, such as HDBC may be easier to use.
Look on Hackage for more options.
I have written an Oracle driver for HDBC largely inspired by Takusen and HSQL. It uses Oracle's OCI library for interfacing with the database.
I consider it experimental for now. But if you want to try it, you can find a darcs repo for it at http://thiagoarrais.com/repos/hdbc-oracle/.
Related
I want to know whether I can use another database engines with Wordpress, other than MySQL or not.
I found this post https://codex.wordpress.org/Using_Alternative_Databases that says no, I can't.
But then I found this one that says I can use SQL Server : http://wordpress.visitmix.com/development/installing-wordpress-on-sql-server and another that says I can use Oracle.
I'm a bit comfused
yes we can use other RDBMS other than MySql. We can use MSSQL, Oracle and PostgreSQL
There is a Database Abstraction Layer present which helps you do this by choosing the driver for which you want to use
I realize this has already been answered, but perhaps someone will find this useful. If you're interested in running MSSQL, I would suggest trying Project Nami. It's an up-to-date fork of WordPress that has fewer limitations than the DB Abstraction plugin.
We have Delphi XE2. We are looking for a database for our application. We have tried Absolute Database and it supports most of SQL commands we need. I see most of Delphi users choose Firebird but it seems to hard to work with. I am so much confused about databases and licenses. Here are my problems:
When we choose a database, let's say Absolute Database, Firebird, MySql embedded etc. and if we have for example 3.000 customers, do we still need to pay to Database developers? Or is it one time fee? I am so much confused because they say when we buy, we can use it inside our building ( http://www.componentace.com/order/licenses.php ). But when we release our software, our customers will need to use the same database of course.
Absolute DB is easy to install and supports most of SQL queries. Firebird does not support most of SQL queries. Is this correct?
When we try to use Firebird, we use FlameRobin to design database. But when we try to connect using IB components, it says "Unable to connect database".
Thank you very much...
Firebird has no licensing fees at all. However, it's smart to help maintain this great project once you rely on it. There is a lot of ways to help Firebird project:
http://www.firebirdsql.org/#consider-your-contribution
Not correct. Firebird is very powerful and supports most SQL standards plus a great SQL extensions for stored procedures and triggers
Check your database connection string. It's usually something like server_ip:full_db_path if you're connecting over a network, or just full_db_path if local. You can always use an ALIAS in place of full_db_path. Make sure you have Firebird server running or, if using embedded, if it's installed correctly. Firebird has a great and very complete documentation and one of the best support groups on open source projects.
It depends on database. Absolute Database is embedded database, everything is included in your exe. Most database engines however are standalone, so they are installed as applications. It looks like if you buy commercial Absolute Database licence, no royalties are needed: http://www.componentace.com/order/order_product.php?id=8
Firebird supports most SQL standards. According to this answer, most SQL compliant embedded database is Firebird: Which embedded database has maximum SQL compliance, and concurrency support?
You must have some configuration issues with IB components, hard to say more without more information. On the otherhand, IB components are for Interbase, so you might find something else better, like UIB.
If you'll choose Firebird, then take a look at IBExpert. This is absolutely the best administration tool available for Firebird. But not cheap. =(
You should also look at Interbase, also marketed by Embarcadero, the Delphi vendor. Interbase is not the same thing as Firebird, which is probably why the IB components you mentioned didn't work.
Yes, each customer will usually have to purchase the IB database. However, there are additional choices with Interbase, depending on how you structure your application. Check how they work and see if they can fit better with what you are trying to do.
I am writing a C program in Unix System Services on a z/OS mainframe. One of the requirements is to get a sequence number from a DB2 database residing on the same mainframe. Not having DB2 Connect available, I'm wondering what my options might be. I can open a socket on port 50000 (the default DB2 port), but, from the IBM documentation I can locate, I am unclear about the rest of the process in this environment.
I have UNIX and DB2 in my background, but I'm just getting my feet wet in the z/OS world, so I'm trying to keep this as straightforward and maintainable as possible.
There is a specific section for ODBC access to DB2/z in the DB2/z 9.1 docs over on publib. Publib should always be the first point of call for any IBM doco.
There's also the DB2/z ODBC PDF.
This is the best way to access DB2/z from C on OE/OMVS/USS (or whatever it's called nowadays). If it was Java, I could probably help out more. The online help was invaluable in getting JREs to talk to the mainframe DB2 (from both USS and PCs) with minimal hassling of our local sysprogs. Of course, it'll be a lot easier with them :-) especially for setting up the z/OS (non-USS) side of things.
Why not use a unix ODBC driver to connect to the database and use the ODBC's sql dialect...it's easy to do...in that way with ODBC the flexibility is there for future maintainability, say switch to a different database provider...see here for an example C code that interacts via ODBC
For C++ I can recommend OTL template library to simplify ODBC interaction. It works with IBM C++ and DB2 for z/OS. Can be used on different platforms.
Link:
Oracle, ODBC and DB2-CLI Template Library
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.
We have a system written in C and running under Solaris & Linux that uses the Sybase CT-library to access a Sybase database.
We generate the table-definitions, indexes, stored procedures and C-code from an in-house developed DDL to reduce the amount of work and errors.
We would like to achieve database independence, so we can add (as a first start) Oracle support.
We're thinking about ODBC or ESQL/C, but having no experience with them.
What solution would you suggest (preferably a cheap and easy one, of course). Is it possible to have a single source solution?
I would highly recommend SQLAPI++ (with the downside, perhaps, that it is a C++ library). There is also unixODBC, though I have never used it in code -- only touched upon it while researching for portable database APIs. POCO also provides a uniform, portable API (though, again, in C++) for database operations, but last I checked it, that part of POCO was only in the initial stages of development.
ODBC will help you write a more portable system, but you will have to be careful to develop your SQL properly if you wish to leverage the underlying database, as the SQL itself may well not be 100% portable across databases, even with the different ODBC drivers.
iodbc
http://www.firstsql.com/iodbc/
or unix odbc
http://www.unixodbc.org/
Are probably among the "most portable" choices.
Regards
Friedrich
ODBC is going to give you far more portability options over ESQL/C.
I've been using iODBC to access SQL Server and mysql and have had pretty good results so far. I think it would work for Oracle as well, but that would depend on the ODBC driver and haven't had to try it so far.