At 19:08 -0500 2/27/03, jasontitus@stripped wrote:
>After wrestling to get everything set up with 4.1, it looks like it
>still does not give the VITAL information of what problems were
>encountered in data loads (on 4.1 2/25/03) -
> mysql> load data infile
>'/Users/jason/Desktop/Hoodata/National1-subset.tab' into table tri;
> Query OK, 91515 rows affected (3.27 sec)
> Records: 91515 Deleted: 0 Skipped: 0 Warnings: 5559
>
> mysql> show warnings;
> Empty set (0.00 sec)
>
> mysql> show errors;
> Empty set (0.00 sec)
>
>When will this ever be fixed? I do not know a SINGLE MySQL DBA who
>has not cursed this lacking as a fundamental design flaw. Not a
>'wouldn't it be nice' feature, but a 'oh my god, you must be kidding
>me' kind of problem.. It continues to make DBAs lives difficult.
>Even Oracle got this one right.
>
>The periodic suggestion of just 'select'ing into an outfile and
>comparing doesn't work too well for most folks who are dealing with
>text fields that may have had trailing spaces, dates in other
>formats, decimal/float numbers that may be displayed differently,
>etc. It is truly a nightmare that seems to never be resolved.
Well, while you're waiting, and if you have Perl DBI installed,
have a look here:
http://www.kitebird.com/mysql-cookbook/examples-ld.php
>
>Is this on track for MySQL 2020, or should I just give up and learn
>to love Oracle and SQL-Plus?
>
>Jason.
>
>p.s. - I am not an ungrateful user of Open Source. For years I was
>a paying MySQL customer and felt confident that this issue would be
>resolved (since it was on the 'Things That Must be Done in the Near
>Future' list), but three or four years later it is still there.
