Strange behaviour in DBConnection

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange behaviour in DBConnection

Günther Schmidt
Hi,

When I connect to an Excel file via dsn-less ODBC I get differt results
when I have a look at the columns.

dbc columns:'Tabelle1$' #displayIt

gives me:

an OrderedCollection(a DBColAttr(1, Katalog, SQL_DOUBLE, 8) a
DBColAttr(2, Autor, SQL_VARCHAR, 510) a DBColAttr(3, Titel,
SQL_LONGVARCHAR, 1073741824) a DBColAttr(4, Beschreibung, SQL_VARCHAR,
510) a DBColAttr(5, Kommentar, SQL_LONGVARCHAR, 1073741824) a
DBColAttr(6, BestNummer, SQL_VARCHAR, 510) a DBColAttr(7, Kapitel/Thema,
SQL_VARCHAR, 510) a DBColAttr(8, EUR, SQL_DOUBLE, 8) a DBColAttr(9,
Schlagworte, SQL_LONGVARCHAR, 1073741824)).

dbc query:'Select * from [Tabelle1$]' #displayIt

returns

a DBResultSet(#(a DBColAttr(1, Katalog, SQL_DOUBLE, 8) a DBColAttr(2,
Autor, SQL_VARCHAR, 255) a DBColAttr(3, Titel, SQL_LONGVARCHAR,
1073741824) a DBColAttr(4, Beschreibung, SQL_VARCHAR, 255) a
DBColAttr(5, Kommentar, SQL_LONGVARCHAR, 1073741824) a DBColAttr(6,
BestNummer, SQL_VARCHAR, 255) a DBColAttr(7, Kapitel/Thema, SQL_VARCHAR,
255) a DBColAttr(8, EUR, SQL_DOUBLE, 8) a DBColAttr(9, Schlagworte,
SQL_LONGVARCHAR, 1073741824)))


The column descriptions varies here, the first one has some columns as
SQL_VARCHAR, 510
and the second one has the very same columns as
SQL_VARCHAR, 255

As soon as I iterate over the result set I get an Index out of Bounds error.

Anybody care to make a guess what's causing this?

Günther


Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour in DBConnection

Blair McGlashan-4
"Günther Schmidt" <[hidden email]> wrote in message
news:[hidden email]...

> Hi,
>
> When I connect to an Excel file via dsn-less ODBC I get differt results
> when I have a look at the columns.
>
> dbc columns:'Tabelle1$' #displayIt
> ...
> [vs]
>... dbc query:'Select * from [Tabelle1$]' #displayIt
> ...
> The column descriptions varies here, the first one has some columns as
> SQL_VARCHAR, 510
> and the second one has the very same columns as
> SQL_VARCHAR, 255
>
> As soon as I iterate over the result set I get an Index out of Bounds
> error.
>
> Anybody care to make a guess what's causing this?
>

Sounds like a problem in the ODBC driver to me.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour in DBConnection

Don Rylander-3
In reply to this post by Günther Schmidt
Günther,
"Günther Schmidt" <[hidden email]> wrote in message
news:[hidden email]...
[...]> DBColAttr(6, BestNummer, SQL_VARCHAR, 510) a DBColAttr(7,
Kapitel/Thema,
[...]> BestNummer, SQL_VARCHAR, 255) a DBColAttr(7, Kapitel/Thema,
SQL_VARCHAR,
[...]> The column descriptions varies here, the first one has some columns
as
> SQL_VARCHAR, 510
> and the second one has the very same columns as
> SQL_VARCHAR, 255
>
> As soon as I iterate over the result set I get an Index out of Bounds
> error.
>
> Anybody care to make a guess what's causing this?

If your concern is the different column widths, I think this is a general
problem with the way Excel columns get interpreted by Microsoft's database
stuff.  I tried to pull data out of Excel a couple of years ago (through
ADO, IIRC), and had similar problems (as does Access).

Again, if I recall correctly, Excel string columns default to 255
characters, padded with spaces (that's annoying!).  If you check your data,
you'll probably find that the first row's data (below the header row with
column names) is 255 or fewer characters, but somewhere in the data you have
a BestNummer value that's 510 characters long.  I suspect it's because
asking for the columns just scans the first couple of rows, while a 'select
*' grabs everything.  So there's a guess worth almost as much as you paid
for it.  ;^)

I suppose the "Index out of Bounds" error might be related, but I don't
specifically remember having that problem.  I'd guess, as Blair says, it's a
driver problem rather than something in Dolphin, but you could always try it
in VBA to check whether you get the same result.  I suspect it will fail
similarly, but with a lot less information.

Given that experience, if I need database features, but have data in Excel,
I've taken to writing little throw-away Smalltalk scripts to collect column
names, data types, and sizes (for text columns).  The script then builds a
CREATE TABLE query in SQL, which I paste into an Access query and execute.
Finally, I use Access to import the data from Excel into my new table.  (If
you import Excel files directly into Access, all text columns are at least
255 characters, which can have a really bad effect on performance with a lot
of records.)

HTH,

Don

>
> Günther