Comme d'autres l'ont dit:
use strict;
use warnings;
En outre, chaque fois que vous faites un appel DBI, vous devez faire ceci:
if ($sth->err()) {
die "ERROR: " . $sth->errstr() . "\n";
}
Même après une extraction. Cela permettra d'attraper beaucoup de problèmes que vous pourriez avoir.
I simplifié votre programme un petit peu:
use strict;
use warnings;
use DBI;
my $connect = DBI->connect("$connectString", "$user", "$id");
if (not $connect) {
die qq(connection error\n);
}
my $table = "session";
my $uniqueSessions = "SELECT DISTINCT SESSION
FROM $table";
print qq(\$uniqueSessions = "$uniqueSessions"\n);
my $queryUniques = $connect->prepare($uniqueSessions);
if ($queryUniques->err()) {
die "ERROR: " . $queryUniques->errstr() . "\n";
}
$queryUniques->execute();
if ($queryUniques->err()) {
die "ERROR: " . $queryUniques->errstr() . "\n";
}
my $session;
$queryUniques->bind_columns(\$session);
my $counter = 1;
my $sessionString;
while(my $hashref = $queryUniques->fetch()) {
print "Fetching Row\n";
if($counter == 1) {
$sessionString = "'" . $session . "'";
} else {
$sessionString = $sessionString . ", '" . $session . "'";
}
$counter++;
}
if ($queryUniques->err()) {
print "ERROR = " . $queryUniques->errstr . "\n";
}
print "$sessionString\n";
je essentiellement pris la deuxième requête et fixé quelques petites choses ici et là. La dernière ligne affiche le $sessionString
qui est une liste de toutes vos sessions séparées par des guillemets. Cette partie a fonctionné.
La deuxième partie est l'endroit où les choses deviennent étranges. Vous prenez $sessionString
et le transmettez comme une instruction SQL. À moins qu'il y ait quelque chose que je ne vois pas, $sessionString
est simplement une liste de sessions et non une instruction SQL en elle-même. Comme je l'ai dit, vérifiez les erreurs avec chaque appel DBI, et voyez si vous faites une erreur quelque part.
Vous pouvez également ajouter une ligne comme celle-ci:
print qq(DEBUG: SQL Query = '$sqlStatement'\n);
avant d'exécuter un $sth->prepare($sqlStatement)
et de cette façon, vous pouvez voir ce que votre instruction SQL est.
Le problème
On dirait que vous préparez la deuxième requête avant de comprendre ce que (?)
devrait être (que je suppose est votre groupe de sessionString $).
Vous devez remplacer les sessions par (?)
AVANT de vous devez faire votre DBI-> prepare().
Quelque chose comme ça (pas testé):
(my $sessionQuery = $query) =~ s/\(\?\)/$sessionString/;
my $querySth = $connect->prepare($sessionQuery);
$querySth->execute();
my @test = $queryPrep->fetchall_arrayref();
Rappelez-vous que la syntaxe qq()
citant est votre ami. J'utilise ce lot:
print qq(DEBUG: \$foo = "$foo"\n);
Et parfois, je simplement copier et coller une déclaration puis citer:
print qq(DEBUG: while (my $foo = foobar($bar)) };\n);
Il est incroyable de voir combien d'erreurs que je peux attraper cette façon. Je peux alors chercher DEBUG:
dans mon programme et supprimer ces lignes.
Rappelez-vous d'écrire vos programmes un peu à la fois, voir si vous pouvez obtenir $sessionString
de travail. Ensuite, essayez de voir si vous pouvez le remplacer dans votre $query
, puis essayez d'exécuter la requête calculée.
Perl est un langage agréable et puissant, mais la syntaxe peut parfois être un peu croustillante - surtout si vous n'êtes pas habitué à Perl orienté objet.
"chaque fois que vous faites un appel DBI, vous devriez faire ceci: if ($ sth-> err())" est si moche. Vous pouvez simplement définir RaiseError => 1 dans l'appel de la méthode connect et toute méthode qui échoue va mourir. – bohica
@bohica Oui, au cours des trois dernières années, j'ai changé mes méthodes de programmation en programmation basée sur les exceptions. Quand j'écris des modules, ils coassent simplement et ne renvoient plus undefs si quelque chose ne va pas. Si vous n'aimez pas cela, enveloppez l'appel dans un 'eval'. J'utilise maintenant 'use autodie;' dans tous mes programmes. Cependant, le point principal est que vous ne devriez pas aveuglément faire confiance à ce que vous obtenez des appels de module. S'ils sont basés sur une exception, enveloppez-les dans un eval, de sorte que vous pouvez gérer l'exception si vous voulez gérer l'erreur avec élégance. –