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

This node falls below the community's minimum standard of quality and will not be displayed.

Replies are listed 'Best First'.
Re: SQL ERROR
by dws (Chancellor) on Nov 15, 2004 at 16:41 UTC

    Please Advise

    Read How do I post a question effectively? and post again, including some code this time.

    Someone might have an answer for you based soley on symptoms, but "it worked before" can also mean "it had a hidden bug that just got exposed." Without code, we can't tell.

    And please don't overwrite the original question. It confuses later readers.

      We defined our arrays by this
      (my $sec0,my $min0,my $hour0,my $mday0,my $mon0,my $year0,my $ +wday0,my $yday0,my $isdst0) = localtime($theLocalTime+86400); (my $sec1,my $min1,my $hour1,my $mday1,my $mon1,my $year1,my $ +wday1,my $yday1,my $isdst1) = localtime($theLocalTime+172800); (my $sec2,my $min2,my $hour2,my $mday2,my $mon2,my $year2,my $ +wday2,my $yday2,my $isdst2) = localtime($theLocalTime+259200); (my $sec3,my $min3,my $hour3,my $mday3,my $mon3,my $year3,my $ +wday3,my $yday3,my $isdst3) = localtime($theLocalTime+345600); (my $sec4,my $min4,my $hour4,my $mday4,my $mon4,my $year4,my $ +wday4,my $yday4,my $isdst4) = localtime($theLocalTime+432000); (my $sec5,my $min5,my $hour5,my $mday5,my $mon5,my $year5,my $ +wday5,my $yday5,my $isdst5) = localtime($theLocalTime+518400); (my $sec6,my $min6,my $hour6,my $mday6,my $mon6,my $year6,my $ +wday6,my $yday6,my $isdst6) = localtime($theLocalTime+604800); @monArray = ($mon0,$mon1,$mon2,$mon3,$mon4,$mon5,$mon6); @mdayArray = ($mday0,$mday1,$mday2,$mday3,$mday4,$mday5,$mday6 +); @wdayArray = ($wday0,$wday1,$wday2,$wday3,$wday4,$wday5,$wday6 +);
      The SQL statement code is this
      $sql = "SELECT facility, department, name, soc, anniversary, years "." +FROM EMPFILE "."WHERE ((anniversary LIKE '".($monArray[0]."/".$mdayAr +ray[0])."') OR " ."(anniversary LIKE '".($monArray[1]."/".$mdayArray[1])."') OR + " ."(anniversary LIKE '".($monArray[2]."/".$mdayArray[2])."') OR + " ."(anniversary LIKE '".($monArray[3]."/".$mdayArray[3])."') OR + " ."(anniversary LIKE '".($monArray[4]."/".$mdayArray[4])."') OR + " ."(anniversary LIKE '".($monArray[5]."/".$mdayArray[5])."') OR + " ."(anniversary LIKE '".($monArray[6]."/".$mdayArray[6])."')) " ."ORDER BY facility, years DESC";
      The error is thrown when I do the prepare statement
      eval{$sqlH = $dbh->prepare($sql);};
Re: SQL ERROR
by dragonchild (Archbishop) on Nov 15, 2004 at 17:38 UTC
    Oof! Ok ... let's get started.
    1. Turn on strict and warnings. I know you're not using either.
    2. When you do that, you'll notice a warning about using a single-element array-slice. What that means is that you're saying @monArray[$i] when you should be saying $monArray[$i].
    3. Your SWITCH thing can be more easily written as:
      $monArray[$i] = sprintf("%02d", $monArray[$i] + 1);
    4. Your SQL statement is appalling. And I mean APPALLING. In so many ways.
      • You don't use placeholders. That means your statements are open to SQL injection attacks.
      • I'm assuming that the anniversary column is a DATE of some sort. So, why don't you do something like (Oracle):
        SELECT foo, bar, baz FROM empfile WHERE anniversary BETWEEN TO_DATE( ?, 'MM/DD' ) AND TO_DATE( ?, 'MM/D +D' )
        That way, you only specify your beginning and your end. Plus, you can give the RDBMS a hint that you want from this date to this date + N days. Doing a little learning will give you tons of benefits.
    5. What's the SQL error you're seeing? Could it be something as simple as "Database not available"? Maybe it has nothing to do with the statement itself ...

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      That way, you only specify your beginning and your end. Plus, you can give the RDBMS a hint that you want from this date to this date + N days.
      If I read the SQL of the OP correct, he is not interested in an interval but in a set of discrete dates without the year. Your SQL-code looks for an interval of dates and would include the year.

      Did you notice that he uses the LIKE-operator but does not include wildcards?

      Oh, yes and he is not using an RDMS either: just plain CSV-files!

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

        Oh, yes and he is not using an RDMS either: just plain CSV-files!

        How on earth do you know this?!? I've been following the thread and I haven't seen this tidbit. If so, I would assume the OP is using DBD::CSV, then. That's ... interesting. I wouldn't argue for it ... in fact, if there's any sort of reasonable work needing to be done in a reasonable time, porting to, at least, DBD::SQLite would be in order. Something that's written in optimized C as the engine for computationally-intensive bits is a must when doing any sort of serious work. This is why we don't use HTTP::Daemon when Apache/mod_perl is available.

        Did you notice that he uses the LIKE-operator but does not include wildcards?

        All that tells me is that the OP (and you) don't understand how DATEs work, especially in SQL. It is very expensive to convert a DATE to a CHAR, then perform a regex against it. Contrast that to using date arithmetic within the RDBMS, which is often optimized to use numeric vs. string comparisions.

        The true solution is to fix the data source so that it's optimized to answer the question. Most RDBMSes will allow for a date to be "year-less", for just this type of query. Look it up.

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Re: SQL ERROR
by Mutant (Priest) on Nov 15, 2004 at 17:17 UTC
    Try printing out your $sql variable. It often makes errors much easier to see. (If not, then try posting the contents of $sql here).
Re: SQL ERROR
by CountZero (Bishop) on Nov 15, 2004 at 18:51 UTC
    <guessing mode="on">It looks as if your DBH-handle is not properly set. Do you check for errors when you connect to the database?<guessing mode="off">

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      I am doing some error checking. Here is my code:
      sub executeQuery { eval{$sqlH = $dbh->prepare($sql);}; if ($@) {print "Database Error: " . $dbh->errstr();exit;} print "Prepared\n"; eval{$sqlH->execute();}; if ($@) {print "Database Error: " . $dbh->errstr();exit;} }
        I think the error might be in your connect statement. Try something like

        my $dbh=DBI->connect(YOUR_CONNECT_INFO_HERE) or die "Cannot connect to the database: $DBI::errstr";

        and see what it says.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law