BaH.DBOracle

This is probably going to be the least-used module I'm in the process of making, since I would imagine that most people here have never even seen an Oracle database in the wild :-p (actually, I'd even go so far as to wager that some didn't even know Oracle was a database company - you'd be surprised).

Setting up the Oracle Client environment is a bit of a schlep, mind you, and that alone will probably keep all the casual interest well away.


Anyways... ;-)

I use Oracle every day (in Java, mostly), so I thought I might as well have a go at implementing an Oracle driver using their OCCI (C++) APIs. The C++ API turns out to look almost exactly like JDBC, which makes my life a whole lot easier.

So far it able to run SQL (like "create table..." etc). Next stop, processing a query. And then finally adding (prepared statement) parameter support.


You next BlitzMax game, with Oracle :-)

Actually I may have some considerable use for this soon, thanks.

Apart from prepared statement support, it appears to be working properly on OSX.

I've had to put it on hold though, as currently the module requires hard-wiring paths to ORACLE_HOME etc, which isn't ideal.

Which has taken me back on the road of BMK hacking, alas...

Isn't this supposed to be the hardest db system to set up in the world?

Setting up the server version is quite involved, yes.
However, I got Oracle Express installed on Ubuntu in about five minutes. It comes with a nice web-interface too, which helps if you aren't an sqlplus expert.

Informix is another one that requires some setup time before you can get into it, although it doesn't have nearly as many options you can change - some might say that's a plus point :-p

The windows build is being somewhat a pain in the rear...

The problem being that since the C++ dll was compiled with MSVC, it requires some glue built on MSVC... which, it turns out that I think my C++ express 2008 is too new.. so I'm installing 2005 now. Hopefully that'll fix the issues I'm having.
My glue appears to be working, just that it's crashing on a call to the oracle dll (which was compiled with 2005). Fingers crossed, etc. ;-)

So much for crossing fingers....

Anyhoo... finally got Win32 support working. Yay!

I've ended up re-writing the glue using a 3rd party library called ocilib, which wraps the OCI API into something manageable. I've built a MinGW version of the ocilib.dll, which all links nicely in BlitzMax. The test app runs and outputs the expected result. Which is a bit of a relief.
Of course, if I didn't want to support Windows, this would have saved me several days of banging head on wall... oh well, we live and learn ;-)

Hope your headache's gone Brucey, I toyed with (oh alright did a module on databases - based on access) a year and a half ago. Have been intrigued by your database modules, just need to think of an appropriate app to send/get stuff from a database. I've got something in progress in B3d:

Is there a way you can envisage a DBase app being useful here:-

http://www.blitzbasic.com/Community/posts.php?topic=80626#908240

I'm using arrays to store individual components of up to 100 cars, would a database be better suited....? Alternatively, if there is some data being populated in an excel data, would it be possible to copy a column at a time of data into a compatible application that would allow interfacing with your mods? Just want to delve back into DBase stuff prior to lots of water disappearing under the bridge(;-)

A small database like SQLite might be useful if you need to be able to store the information, for retrieval at a later date. If the data is fairly static, it might not be worth going to the trouble of plugging in a fully-fledged database. (ie. you could stick it in a text file, and load it)
If the data changes over time, or perhaps you want to add to the data as time progresses, a database can be useful. (insofar as that is what it is designed to do).
For small data-sets, a database is overkill.
For large data-sets, it will make your life easier to manage that data.


It would essentially be a list of textual entries. So yes, it wouldn't be too difficult to insert the data into a database.

The database modules simply open a door to easily accessing many different database types through a common interface - rather than having to learn an (often convoluted) API. ;-)

Righty... so that's it working on the three platforms now.
Recently updated the "helper" library (ocilib) to v3, and got prepared statements up and running, which covers most of the functionality. Still some dbtypes to add support for (time stuff mostly).

Next up will be the docs... getting things working with Oracle tends to require a lot of setting up. However, anyone that's likely to want to use it will be used to that anyway, so the docs will probably make a lot of assumptions - otherwise I'd end up having to write a book!
Still, native Oracle support is nice :-)

I think I'll forget about an Informix driver... since getting that working is even more fiddly... and I don't like the client installers much - what's with having to take over your system just to add some shared objects?
I might take another look at Firebird. Perhaps the cpp libs are a bit more mature now. Didn't get very far the last time.
Other than DB2, which I'm still open to, are there any other databases which have cross-platform client libraries?