Обсуждение: Re: psqlODBC Unicode 8.01.02.00 Driver "Overflows" On MS-Access

Whenever I get these I write a tiny "stuff one record in and tell me if
it errors" iteration. Just leave that running and get on with something
else productive.

Tim Clarke

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Andreas
> Sent: 15 March 2006 19:39
> To: Randy Yates
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] psqlODBC Unicode 8.01.02.00 Driver
> "Overflows" On MS-Access
>
>
> I had one of these, too.
>
> The date wasn't correctly formated in the Access table.
> It was something like   11/1/106   which should have been entered as
> 1/11/2006.
>
> It was a wee bit unpleasant to actually locate the line
> within the table.
> I limited the export to chunks by a numeric primary key.
> First 1000 then
> gradually narrowing down to the bad record.
> I'd be cute if the error message contained some form of
> identifier like
> the primary key. On the other hand how should odbc know what
> column of
> some SELECT is an identifier?

Tim.Clarke@manifest.co.uk ("Tim Clarke") writes:

> Whenever I get these I write a tiny "stuff one record in and tell me if
> it errors" iteration. Just leave that running and get on with something
> else productive.

I think the point is, if the driver error messages were a little more
intelligent (including some context) to begin with, then you (and a
bazillion others) wouldn't have to take any extra time to begin with.
It would be an instant "Oh, I see the problem."

It might also be helpful if the driver converted all records it was
able to convert and not simply abort on the first record with an
error.
--
%  Randy Yates                  % "Maybe one day I'll feel her cold embrace,
%% Fuquay-Varina, NC            %                    and kiss her interface,
%%% 919-577-9882                %            til then, I'll leave her alone."
%%%% <yates@ieee.org>           %        'Yours Truly, 2095', *Time*, ELO
http://home.earthlink.net/~yatescr

Randy Yates wrote:
> Tim.Clarke@manifest.co.uk ("Tim Clarke") writes:
>
>
>>Whenever I get these I write a tiny "stuff one record in and tell me if
>>it errors" iteration. Just leave that running and get on with something
>>else productive.
>
>
> I think the point is, if the driver error messages were a little more
> intelligent (including some context) to begin with, then you (and a
> bazillion others) wouldn't have to take any extra time to begin with.
> It would be an instant "Oh, I see the problem."

As far as I see, it's MS-Access not the ODBC driver which rsports the
*Overflows*.

> It might also be helpful if the driver converted all records it was
> able to convert and not simply abort on the first record with an
> error.

Unfortunately the ODBC driver itself doesn't detect any error before
MS-Access calls SQLEndTran.

regards,
Hiroshi Inoue

inoue@tpf.co.jp (Hiroshi Inoue) writes:

> Randy Yates wrote:
>> Tim.Clarke@manifest.co.uk ("Tim Clarke") writes:
>>
>>>Whenever I get these I write a tiny "stuff one record in and tell me if
>>>it errors" iteration. Just leave that running and get on with something
>>>else productive.
>> I think the point is, if the driver error messages were a little more
>> intelligent (including some context) to begin with, then you (and a
>> bazillion others) wouldn't have to take any extra time to begin
>> with. It would be an instant "Oh, I see the problem."
>
> As far as I see, it's MS-Access not the ODBC driver which rsports the
> *Overflows*.

How can you tell?

>> It might also be helpful if the driver converted all records it was
>> able to convert and not simply abort on the first record with an
>> error.
>
> Unfortunately the ODBC driver itself doesn't detect any error before
> MS-Access calls SQLEndTran.

I don't understand your statements. Is it not the driver that is performing
the conversions?

If it is MS, then of course that explains everything ...
--
%  Randy Yates                  % "Bird, on the wing,
%% Fuquay-Varina, NC            %   goes floating by
%%% 919-577-9882                %   but there's a teardrop in his eye..."
%%%% <yates@ieee.org>           % 'One Summer Dream', *Face The Music*, ELO
http://home.earthlink.net/~yatescr

Randy Yates wrote:
> inoue@tpf.co.jp (Hiroshi Inoue) writes:
>
>
>>Randy Yates wrote:
>>
>>>Tim.Clarke@manifest.co.uk ("Tim Clarke") writes:
>>>
>>>
>>>>Whenever I get these I write a tiny "stuff one record in and tell me if
>>>>it errors" iteration. Just leave that running and get on with something
>>>>else productive.
>>>
>>>I think the point is, if the driver error messages were a little more
>>>intelligent (including some context) to begin with, then you (and a
>>>bazillion others) wouldn't have to take any extra time to begin
>>>with. It would be an instant "Oh, I see the problem."
>>
>>As far as I see, it's MS-Access not the ODBC driver which rsports the
>>*Overflows*.
>
>
> How can you tell?

I can reproduce a similar (not sure if exactly the same) case here.
When I run the 1 row test case with mylog output and ODBC trace on,
I find a SQLTransact(.., SQL_ROLLBACK) call suddenly after some
SQLBindParameter calls in the trace log without any surrounding errors.

regards,
Hiroshi Inoue