Re: Application Error

sub __select_recordset{
    my $loc_select = shift;    #SQL SELECT clause
    my $loc_from = shift;    #SQL FROM clause including join, if any
    my $loc_where = shift;    #SQL WHERE clause
    my $loc_order = shift;    #SQL ORDER BY clause
    my $loc_sth ;            #Statement handle
        my $loc_sql_string;     # Complete SQL string without ";"
        #
        #   Removes leading and training whitespace from parameters.
        #
        if (__trim($loc_where) ne "" ){
            $loc_sql_string = "select ".__trim($loc_select)." from "._
+_trim($loc_from)." where ".__trim($loc_where)." order by ".__trim($lo
+c_order);
        } else {
             $loc_sql_string = "select ".__trim($loc_select)." from ".
+__trim($loc_from)." order by ".__trim($loc_order);
        }

    $loc_sth=$gl_dbh->prepare($loc_sql_string) or die "Can't prepare s
+ql statement" . DBI->errstr;
    $loc_sth->execute() or die "Can't execute sql statement" . DBI->er
+rstr;
        return $loc_sth;
}
[download]

I have a few comments:
1. In Perl there is normally not a good reason for using double underscore before a sub name. I am curious as to why you are doing that?
2. Your preamble to select_recordset() could be shorter:

sub select_record_set
{
   my ($SQL_select_clause,    #I just named the vars according to
       $SQL_from_clause,      #your comment code
       $SQL_where_clause,     #pick new names if you like
       $SQL_order_by_clause,  #pick a name that renders 
                              #the #comment useless
       ) = @_;
       
   my $statement_handle = (); #not sure that you need these
   my $sql_string = ();       #vars
   
   # I get lost here....
   # prepare(),  execute()
   
   # for that matter, if you are passing in an SQL statement,
   # why do you need the $SQL vars above? Prepare the statement and
   # then run it.
}
[download]

I will defer to SQL DB Monks. I don't understand how your code is supposed to work.

Comment on Re: Application Error Select or Download Code

Replies are listed 'Best First'.
Re^2: Application Error by Steve_BZ (Chaplain) on Aug 12, 2009 at 11:58 UTC
Hi Marshall, Thanks for your ideas. I liked idea of naming your variables to render the comments useless very much. I don't know that I could always do it, because the names might become very long, but it's a good check to apply. On the subroutines, I copied a bit of perl off the internet that I liked and it used the double underscore technique. I thought it was a good way of identfying subroutines very quickly and easily. Do you think it creates a problem? Steve	[reply]
Re^3: Application Error by Marshall (Canon) on Aug 14, 2009 at 18:26 UTC
Coming up with "good" variable names meaning: descriptive, understandable and "short" names is an art form. Practice matters. Your response reminded me of one the best ASM drivers I've ever read (from 30+ years ago). In those days limit was 5 letters, all CAPS for a var name. That was it! "ABCDE". I read this guy's code and I understood it. There were 2 comments in the ASM code: 1)"Suck it in" and 2) "blow it out". This guy was at a level that extremely few will ever achieve in terms of clarity, efficiency, brevity. I think we should ALL strive for descriptive names. I did some simple "translation" above. The underscore thing is a name space thing. I will defer to other Monks on the wisdom of that in OO modules. This is basically Perl OO thing that means that this is a private function that I my convention will not export and you should not call and thing with a name like that.	[reply]