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

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