Re: use of DBI; I am getting multiple error messages mixed in with the correct output.

On Apr 24, 10:56 am, Ted Zlatanov <t...@xxxxxxxxxxxx> wrote:
On Wed, 23 Apr 2008 14:40:14 -0700 (PDT) Ted <r.ted.by...@xxxxxxxxxx> wrote:

T> This would be a useful tidbit to add to the documentation.  I hadn't
T> expected a mature library like DBI to behave like this.  I do not, for
T> example, have to go through any such extra hoops when using JDBC with
T> JSF.  If a particular record set contains nulls in one or more columns
T> in one or more records, JSF automagically displays it as an empty
T> string; something I have modified on occassion to display the string
T> "N/A".

I saw your discussion with the others, it covered all the bases.  I
agree with Abigail (unsurprisingly), but I also think the current DBI
approach is the best compromise between ideology and pragmatism.

She is a gem, isn't she?!!

I learned plenty about the perl side of things from her posts. And I
found Ben's last example, using undef to ignore certain values,
interesting. But his first example remains problematic. Between the
two, and others, I can see some logic in choosing undef as a pel
primitive to represent SQL NULLS, but it seems to me that with the
support now available for object oriented programming in perl, it
would have been relatively trivial to provide a new class to more
closely represent the SQL idea of a null. When I did it in Java, all
I had to do was add a private data member of type boolean, and then
check this data member in those member functions where it is relevant
that override functions provided in the relevant base classes.

T> You needn't worry about rewriting the whole thing as I'll be doing
T> that anyway as I learn to translate more of what I know from C++,Java
T> and SQL into Perl.  But perhaps you could give me a break and make
T> some suggestions as to what improvements you'd recommend and where to
T> look for details in the documentation.  

Use an options hash with Getopt::Long.

Instead of $$var[$i], use $var->[$i].

Learn about join, map, and grep.

Have fun.  Always look for a shorter, smarter way to do something.

Thank you.

T> And one thing I haven't found yet, which I am sure must be there
T> somewhere, is how to set up a bulk insert.  Can you point me in the
T> right direction to see how to do that using DBI?

Bulk inserts are annoyingly hard to do in a generic way.  You've got to
do it with the database's particular facility.  Postgres, for example,
has a statement that will import a file; Sybase has an entirely external
utility for this task and no internal functionality.

Yuck. Another pet peeve WRT DB programming and portability. I can
get correct C+ code to compile using almost any compiler, especially
if I avoid vendor provided extensions, and the same remains true of my
fortran code, but it seems notoriously hard to develop portable SQL
code (my mix is MS SQL Server 2005, Postgres and MySQL. But it is
trivially easy to perform bulk loads using the DB's particular
facility, and thus not especially challenging to set up in Perl using,
e.g., system. And it has been pointed out later on in this thread
that MySQL's bulk load can be invoked through a DB handle.

BTW: having read the thread, you see where Ben and I seem to be
butting heads. Can you point me to places in the Perl reference that
substantiate his perspective on the points where we disagree, and
which provide a fuller explanation of his point of view?

Thanks

Ted
.