Steve_BZ has asked for the wisdom of the Perl Monks concerning the following question:

I'm getting a perl.exe - Application error that is defeating all my best attempts to debug. I have a routine that has been working perfectly for a while and now I have added some more code that accesses it only for the original code to crash. I am using Komodo 5, so I had hopped that Komodo would catch it and give me a reason code, but no. I have a firebird database, accessed using DBI. Here is the crashing code: 
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]
and here is the SQL in ,$loc_sql_string

"select tbl_patient_exam.att_patient_examination_dte, tbl_patient_exam.att_patient_exam_time_dte, tbl_patient_exam.att_patient_ref_3_org_txt, tbl_patient_exam.att_patient_ref_3_txt, tbl_patient_exam.att_examining_doctor_id_txt, tbl_patient_exam.att_referring_doctor_id_txt, tbl_patient_exam.att_patient_exam_status_txt, tbl_patient_exam.att_vitals_endoscopy_txt, tbl_patient_exam.att_vitals_blood_pressure_txt, tbl_patient_exam.att_vitals_pulse_txt, tbl_patient_exam.att_vitals_height_txt, tbl_patient_exam.att_vitals_weight_txt, tbl_patient_exam.att_vitals_o2_txt, tbl_patient_exam.att_vitals_patient_field_1_txt, tbl_patient_exam.att_vitals_patient_field_2_txt, tbl_patient_exam.att_vitals_patient_field_3_txt, tbl_patient_exam.att_vitals_patient_field_4_txt, tbl_patient_exam.att_vitals_patient_field_5_txt from tbl_patient_exam where tbl_patient_exam.att_patient_id_txt = '1' order by tbl_patient_exam.att_patient_id_txt"

Which works perfectly when cut and paste into my SQL engine.

The error is 'The instruction at "0x7c910f1e" referenced memory at "0x00580054". The memory could not be "read"

Click on OK to terminate program
Click on Cancel to debug program'

Neither of which shed any light on the problem.

I wondered if I had built up some memory problem causing a stack overflow by not disconnecting properly, so I set dbh as a global variable and opened it once at the beginning of the programme. The only strange thing is that the error disappears when I remove
"tbl_patient_exam.att_vitals_patient_field_1_txt, tbl_patient_exam.att_vitals_patient_field_2_txt, tbl_patient_exam.att_vitals_patient_field_3_txt, tbl_patient_exam.att_vitals_patient_field_4_txt,"

But the exact same SQL still works in a previous version of the program.

Replies are listed 'Best First'.
Re: Application Error
by Anonymous Monk on Aug 12, 2009 at 04:10 UTC
    You probably need to upgrade whichever DBD (and underlying library) you are using. You should report the bug to the developers.
[reply]
      OK, thanks for this. I upgraded the DBI & ODBC functions, the DB error has disappeared revealing a much more ordinary window layout error.

      Thanks very much for your help.

      Regards

      Steve
[reply]
Re: Application Error
by Marshall (Canon) on Aug 12, 2009 at 04:53 UTC
    Read more... (2 kB)
    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.
[reply]
[d/l]
[select]
      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]
        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]

Back to Seekers of Perl Wisdom