Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Firstly apologies if this question seems like a wall of text, I can't think of a way to format it.

I have a machine with valuable data on (circa 1995), the machine is running UNIX (SCO OpenServer 6) with an unknown database stored on it.

The data is normally accessed via a software package of which the license has expired and the developers are no longer trading.

The software package connects to the machine via telnet to retrieve data and modify data (the telnet connection no longer functions due to the license being changed).

I can access the machine via an ODBC driver (SeaODBC.dll) over a network, this was how I was planning to extract the data but so far I have retrieved 300,000 rows in just over 24 hours, in total I estimate there will be around 50,000,000 rows total so at current speed it will take 6 months!

I've played around with the UNIX interface and the only large files I can find are in a massive matrix of single character folder (eg A>G>data, A>H>data ect).

I need either a quicker way to extract the data from the machine via ODBC or a way to extract the entire DB locally on the machine to an external drive/network drive or other external source.

Does anyone know how to find out the installed DB systems on the machine? Hopefully it is a standard and I'll be able to find a way to export everything into a nicely formatted file!

share|improve this question

Some things to try, in no particular order:

  • file(1) might be able to identify the files
  • Any strange, not mounted disk partitions could be raw devices
  • Rummage around in /etc/init.d (or whatever system it uses to start services), the database was probably started from there somehow.
  • strings(1) applied to executables often help to identify callouts, version strings and such
  • If the license expired, you could try just setting the date back...
  • Perhaps googling for the vendor of the package gives some hints at their favorite databases
  • Just copy the whole disk elsewhere, and analyze it on a more capable machine
  • I worked with a SCO system a long while back, and it was a royal pain. But it had a rudimentary package management system then, and third party packages were installed using it. Perhaps you can persuade it to tell what was installed.
share|improve this answer
up vote 1 down vote accepted

I finally solved the problem, running a query using another tool (not through MS Access or MS Excel) worked massively faster, ended up using DaFT (Database Fishing Tool) to SELECT INTO a text file. Processed all 50 million rows in a few hours.

It seems the dll driver I was using doesn't work well with any MS products.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.