Re: Is there an idiots guide to writing an ODBC driver?

Morning

Thanks for this.

I ended up here as I tried the forum that suggets which forums to post to.

My main issue is that the files are supplied as VSAM files and we can not
get them as CSV files. We are being sent backup tapes, potentially 50 per
month with about 30 VSAM files per backup.

Just to be totally clear, I know no way of loading/importing a VSAM file
into Access.

So I either have to write a program to unload each VSAM file to a CSV file
and then import this file or write a stripped down ODBC driver so that this
conversion step can be avoided.

The ODBC driver is a more elegant solution.

I apppreciate that as a method of simply reading a whole file ODBC is
overkill/inappropriate, but it fits more neatly into the environment. People
know how to select an ODBC datasource in Access, they do it a lot against SQL
Server databases, so the concept is not strange.

Like you suggest I envisage these VSAM files being read into a temporary
table and the required information being moved into Access/SQL Server tables.

Bye

Ian

"Chris Mills" wrote:

You might want to ask in some related newsgroups, like C newsgroups, or some
other Access ng's like "externaldata". I think it's an unusual request.

For myself, and possibly most, imports via csv, xls, into Access tables is the
more usual route.

An ODBC driver is for manipulating some external data source directly (or so I
think, usually), whereas you just want to import(load is what you said). I
would think that is best served by indeed "loading it" (importing into Access,
rather than ODBC which does not actually load it but connects to it, with
possibly attendant speed problems)

For myself, if I wasn't sure what needed to be imported into (Access), then I
guess I'd import the data into a Temp Table, and use some queries to vet the
data from there into "main tables". In fact, I did such a thing just yesterday
(import csv data), and rather than mess-up the nice "Front-End" with "temp
tables", I just gave them a separate "front-end" mdb to be used on this
occasion (or several-who cares).

Anyway, it doesn't sound like the right newsgroup to discover how to write an
ODBC driver? Just for data imports?
Chris

"Ian Smith - IS Associates" <Ian Smith - IS
Associates@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:43362CC3-2A47-4BBA-89F6-82DD8D446352@xxxxxxxxxxxxxxxx
Morning

We will be receiving some data files on a regular basis, these files are in
a version of VSAM.

We want to load these into Access.

I want to write a minimum possible ODBC driver that supports SELECT * FROM
<FileName> In the same way that the Access text driver does. From here on
normal Access users will be able to cope, by loading the result into an
Access table.

I appreciate that it if were for distribution, file based odbc drivers have
to implement a whole SQL engine, but it wil be for internal use only so we
can be a bit naughty and only support what is needed and flag an error for
WHERE clauses, INSERTs etc!

We do have file format documentation and it may be easier to write a routine
to dump the files as text files and then load the text files but this is not
the prefered solution.

I am a very experienced c++/assembler programmer but I have never written an
ODBC driver.

Any ideas?

Thanks

Ian Smith







.

Loading