in reply to Re: DBI bug?
in thread DBI bug?

I've tried with placeholders and still doesn't works (I've foreseen this, since I'm not using placeholders in the other dozens of scripts that do similar things in the app).

I've thought about the 'cached' part too, since the 'Alloc' part of the error msg really indicates a problem caching the query. Well, it's not this. I've tryied without caching and the result is the same.

I've Googled for this particular error msg and there's only one result that really matters and the guy who posted the same question that I did received no response, so I think this is a very serious problem.

I can only think on blaming Access, since the whole script where the snippet that I've posted came from is really big. Maybe MS Access can't handle it? I'm really perlplexed...

Thanks anyway for your reply.

my ($author_nickname, $author_email) = ("DaWolf","erabbott\@terra.com.br") if ($author_name eq "Er Galvão Abbott");

Replies are listed 'Best First'.
Re: Re: Re: DBI bug?
by perlplexer (Hermit) on May 06, 2002 at 13:19 UTC
    Have you tried what gmax had suggested?
    Enable tracing right before the prepare_cached() and see what you get;e.g.,
    DBI->trace(2, 'dbitrace.txt'); $sthn = $dbh->prepare_cached("SELECT DISTINCT nome FROM usuarios WHERE + login=? AND filial=?") or die "ERRO!"; $sthn->execute($gerente, $filial);
    Run your program and see what you get in 'dbitrace.txt'

    --perlplexer
Re: Re: Re: DBI bug?
by Fastolfe (Vicar) on May 07, 2002 at 18:20 UTC
    Unless your variables are coming from trusted sources or you're doing some serious sanitization prior to using them in your SQL, you should be using placeholders anyway. Don't let the user stick a single-quote in your input and let them inject their own SQL into your statement. Placeholders/bind variables are secure, and allow your SQL to be re-used, so it's faster and more efficient. Plus, it makes your code more readable. Just some tips, good luck.