in reply to SQL ERROR

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.

Replies are listed 'Best First'.
Re^2: SQL ERROR
by CountZero (Bishop) on Nov 15, 2004 at 19:01 UTC
    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.

        The error-string is a dead give-away: DBD::CSV::st execute failed:

        I'm quite sure DBD::CSV does not know how to use "year-less" dates.

        Indeed his SQL is strange (as you already pointed out), but you should not infer from the OP's knowledge of SQL, what my level of knowledge of SQL is.

        CountZero

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