Thread: ODBC into Access...

Morning...

    Well, I've finally been forced to use Micro$loth for a project
*sigh*  But, thank god, its purely to provide a front-end for a client, so
I can live with it...

    But, the question is...the table that I'm creating consists of
fields of int4[] (an array), where element 1 is an answer, and element 2
is a score associated with that answer...

    How (if it does?) will Access be able to handle this?

Thanks...

The Hermit Hacker wrote:

> Morning...
>
>         Well, I've finally been forced to use Micro$loth for a project
> *sigh*  But, thank god, its purely to provide a front-end for a client, so
> I can live with it...
>
>         But, the question is...the table that I'm creating consists of
> fields of int4[] (an array), where element 1 is an answer, and element 2
> is a score associated with that answer...
>
>         How (if it does?) will Access be able to handle this?
>

Good Afternoon,

The driver handles all none standard data types as text.    The resulting
behavior will probably vary some with each application and data type.   In the
case of int4[] and MS Access 97 it does an effective job.     The array can be
displayed and updated cleanly.     Arithmetic is a little tricky.    MS Access
complains about "t.a[1]" in the query builder.    It does not like the syntax
and never sends it to the backend.

The work around is to choose the SQL Pass-thru option.  This will allow you to
build expressions like "t.a[0] * t.a[1]".    The hassle is that every time you
run the query in Access 97 it prompts you with a database connection dialog.

MS Excel in combination w/ MS Query may provide a better solution.  It passes
every query through.. I try to stay away from the more exotic types if I know
I am going to expose them to the public.

On Wed, 22 Apr 1998, David Hartwig wrote:

> MS Excel in combination w/ MS Query may provide a better solution.  It passes
> every query through.. I try to stay away from the more exotic types if I know
> I am going to expose them to the public.

Generally I'd feel the same way, except, in this case, its a 130 question
questionnaire that we're loading in, and they need both "answer" and
"score" recorded :(  I figured an array would be great for this, since the
only other alternative I could think of was have one table for answers and
one for scores...which I *think* would be messy :(

Access was what I was going to use for testing, but if Excel should do a
better job of it, I'll work that route instead.  Worst case, I waste time
trying this and have to revert to doing it the other way *shrug*

Thanks :)