Peut-on à partir d'une même connexion DBI effectuer 2 parcours
fetchrow_array imbriqués (sur 2 requêtes select) ? (J'ai essayé et
suite au 2nd fetchrow sur la 2nd requete, j'ai une erreur sur le 1er
qui semble retourner le résultat de la 2nd requête et non plus celui de
la 1ère). En espérant avoir été clair (sinon je posterai un exemple de
code)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Caron
Salut,
On Thu, 02 Feb 2006 23:14:11 +0100, j!hem wrote:
Peut-on à partir d'une même connexion DBI effectuer 2 parcours fetchrow_array imbriqués (sur 2 requêtes select) ?
A condition d'utiliser deux "statement handles" (habituellement appelé $sth, le retour de $dbh->prepare(...), utilisé pour faire le $sth->execute(...) et le $sth->fetchrow_array):
my $sth = $dbh->prepare("SELECT id FROM table1"); $sth->execute(); while (my ($id1) = $sth->fetchrow_array()) { print "table 1 id = $id1n";
my $sth2 = $dbh->prepare("SELECT id FROM table2 WHERE ref=?"); $sth->execute($id1); while (my ($id2) = $sth->fetchrow_array()) { print " table 2 id = $id2n"; } }
Sinon on peut aussi utiliser selectall_arrayref:
my $id1s = $dbh->selectall_arrayref("SELECT id FROM table1"); die if !$id1s; for my $id1 (@$id1s) { print "table 1 id = $id1n";
my $id2s = $dbh->selectall_arrayref("SELECT id FROM table2 WHERE ref=?",undef,$id1); next if !$id2s; for my $id2 (@$id2s) { print " table 2 id = $id2n"; } }
Bien entendu, dans certains cas il peut être plus efficace de combiner les deux requêtes avec une jointure SQL, mais ça dépend beaucoup de ce qu'on cherche à faire...
Jacques. -- Oxado http://www.oxado.com/
Salut,
On Thu, 02 Feb 2006 23:14:11 +0100, j!hem wrote:
Peut-on à partir d'une même connexion DBI effectuer 2 parcours
fetchrow_array imbriqués (sur 2 requêtes select) ?
A condition d'utiliser deux "statement handles" (habituellement appelé
$sth, le retour de $dbh->prepare(...), utilisé pour faire le
$sth->execute(...) et le $sth->fetchrow_array):
my $sth = $dbh->prepare("SELECT id FROM table1");
$sth->execute();
while (my ($id1) = $sth->fetchrow_array())
{
print "table 1 id = $id1n";
my $sth2 = $dbh->prepare("SELECT id FROM table2 WHERE ref=?");
$sth->execute($id1);
while (my ($id2) = $sth->fetchrow_array())
{
print " table 2 id = $id2n";
}
}
Sinon on peut aussi utiliser selectall_arrayref:
my $id1s = $dbh->selectall_arrayref("SELECT id FROM table1");
die if !$id1s;
for my $id1 (@$id1s)
{
print "table 1 id = $id1n";
my $id2s = $dbh->selectall_arrayref("SELECT id FROM table2 WHERE
ref=?",undef,$id1);
next if !$id2s;
for my $id2 (@$id2s)
{
print " table 2 id = $id2n";
}
}
Bien entendu, dans certains cas il peut être plus efficace de combiner les
deux requêtes avec une jointure SQL, mais ça dépend beaucoup de ce qu'on
cherche à faire...
Peut-on à partir d'une même connexion DBI effectuer 2 parcours fetchrow_array imbriqués (sur 2 requêtes select) ?
A condition d'utiliser deux "statement handles" (habituellement appelé $sth, le retour de $dbh->prepare(...), utilisé pour faire le $sth->execute(...) et le $sth->fetchrow_array):
my $sth = $dbh->prepare("SELECT id FROM table1"); $sth->execute(); while (my ($id1) = $sth->fetchrow_array()) { print "table 1 id = $id1n";
my $sth2 = $dbh->prepare("SELECT id FROM table2 WHERE ref=?"); $sth->execute($id1); while (my ($id2) = $sth->fetchrow_array()) { print " table 2 id = $id2n"; } }
Sinon on peut aussi utiliser selectall_arrayref:
my $id1s = $dbh->selectall_arrayref("SELECT id FROM table1"); die if !$id1s; for my $id1 (@$id1s) { print "table 1 id = $id1n";
my $id2s = $dbh->selectall_arrayref("SELECT id FROM table2 WHERE ref=?",undef,$id1); next if !$id2s; for my $id2 (@$id2s) { print " table 2 id = $id2n"; } }
Bien entendu, dans certains cas il peut être plus efficace de combiner les deux requêtes avec une jointure SQL, mais ça dépend beaucoup de ce qu'on cherche à faire...
Jacques. -- Oxado http://www.oxado.com/
j!hem
Jacques Caron a couché sur son écran :
Salut,
On Thu, 02 Feb 2006 23:14:11 +0100, j!hem wrote:
Peut-on à partir d'une même connexion DBI effectuer 2 parcours fetchrow_array imbriqués (sur 2 requêtes select) ?
A condition d'utiliser deux "statement handles" (habituellement appelé $sth, le retour de $dbh->prepare(...), utilisé pour faire le $sth->execute(...) et le $sth->fetchrow_array):
my $sth = $dbh->prepare("SELECT id FROM table1"); $sth->execute(); while (my ($id1) = $sth->fetchrow_array()) { print "table 1 id = $id1n";
my $sth2 = $dbh->prepare("SELECT id FROM table2 WHERE ref=?"); $sth->execute($id1); while (my ($id2) = $sth->fetchrow_array()) { print " table 2 id = $id2n"; } }
Sinon on peut aussi utiliser selectall_arrayref:
my $id1s = $dbh->selectall_arrayref("SELECT id FROM table1"); die if !$id1s; for my $id1 (@$id1s) { print "table 1 id = $id1n";
my $id2s = $dbh->selectall_arrayref("SELECT id FROM table2 WHERE ref=?",undef,$id1); next if !$id2s; for my $id2 (@$id2s) { print " table 2 id = $id2n"; } }
Bien entendu, dans certains cas il peut être plus efficace de combiner les deux requêtes avec une jointure SQL, mais ça dépend beaucoup de ce qu'on cherche à faire...
Jacques.
Bonjour, Merci pour cette réponse. En fait, j'ai réalisé le code ci-après. La variante, en commentaire, consiste à faire le prepare/execute sans employer la fonction "sql". Au début, je pensais que c'était elle posait problème... (dans le genre retourne la même référence pour les 2 exécute). Et ça ne marche toujours pas : après l'exécution de la seconde requête, j'ai une erreur DBI sur le nombre d'éléments lors de l'exécution du $stm1=sql($dtbh,"select oid,dmesg,delta from cal");
J'utilise : - ActivePerl 5.8.7 - DBD-PgPP 0.4.0.0 - DBI 1.48 Ah, j'oubliais... dernier détail : je suis sous Linux Gentoo 2004.3. (Mais j'ai fait un test sous Windows avec les mêmes version et j'obtiens le même résultat... :/ )
#!/usr/bin/perl -w use strict; use warnings; use DBI;
sub sql { my $dtbh=shift; my $sqlo=shift; print $sqlo . "n"; my $stmh=$dtbh->prepare($sqlo); return $stmh->execute() ? $stmh : undef; }
my %attr=( PrintError => 1, RaiseError => 0 );
my $dtbhÛI->connect('dbi:PgPP:dbname=miggum;host=localhost;portT32','postgres','xxxxxxxx',%attr); if (defined $dtbh) { my $stm1=sql($dtbh,"select oid,dmesg,delta from cal"); while (my ($oid,$dmesg,$delta)=$stm1->fetchrow_array()) { print "$oid,$dmesg,$deltan"; my $stm2=sql($dtbh,"select oid,prgrm from pst where dmesg='$dmesg'");
#my $stm2=$dtbh->prepare("select oid,prgrm from pst where dmesg='$dmesg'"); #$stm2->execute();
while (my ($oid,$prgrm)=$stm2->fetchrow_array()) { print "$oid,$prgrmn"; } } $dtbh->disconnect(); }
-- Cordialement, Jean-Marc "j!hem" QUERE
Jacques Caron a couché sur son écran :
Salut,
On Thu, 02 Feb 2006 23:14:11 +0100, j!hem wrote:
Peut-on à partir d'une même connexion DBI effectuer 2 parcours
fetchrow_array imbriqués (sur 2 requêtes select) ?
A condition d'utiliser deux "statement handles" (habituellement appelé $sth,
le retour de $dbh->prepare(...), utilisé pour faire le $sth->execute(...) et
le $sth->fetchrow_array):
my $sth = $dbh->prepare("SELECT id FROM table1");
$sth->execute();
while (my ($id1) = $sth->fetchrow_array())
{
print "table 1 id = $id1n";
my $sth2 = $dbh->prepare("SELECT id FROM table2 WHERE ref=?");
$sth->execute($id1);
while (my ($id2) = $sth->fetchrow_array())
{
print " table 2 id = $id2n";
}
}
Sinon on peut aussi utiliser selectall_arrayref:
my $id1s = $dbh->selectall_arrayref("SELECT id FROM table1");
die if !$id1s;
for my $id1 (@$id1s)
{
print "table 1 id = $id1n";
my $id2s = $dbh->selectall_arrayref("SELECT id FROM table2 WHERE
ref=?",undef,$id1);
next if !$id2s;
for my $id2 (@$id2s)
{
print " table 2 id = $id2n";
}
}
Bien entendu, dans certains cas il peut être plus efficace de combiner les
deux requêtes avec une jointure SQL, mais ça dépend beaucoup de ce qu'on
cherche à faire...
Jacques.
Bonjour,
Merci pour cette réponse. En fait, j'ai réalisé le code ci-après.
La variante, en commentaire, consiste à faire le prepare/execute sans
employer la fonction "sql". Au début, je pensais que c'était elle
posait problème... (dans le genre retourne la même référence pour les 2
exécute). Et ça ne marche toujours pas : après l'exécution de la
seconde requête, j'ai une erreur DBI sur le nombre d'éléments lors
de l'exécution du $stm1=sql($dtbh,"select oid,dmesg,delta from cal");
J'utilise :
- ActivePerl 5.8.7
- DBD-PgPP 0.4.0.0
- DBI 1.48
Ah, j'oubliais... dernier détail : je suis sous Linux Gentoo 2004.3.
(Mais j'ai fait un test sous Windows avec les mêmes version et
j'obtiens
le même résultat... :/ )
#!/usr/bin/perl -w
use strict;
use warnings;
use DBI;
sub sql {
my $dtbh=shift;
my $sqlo=shift;
print $sqlo . "n";
my $stmh=$dtbh->prepare($sqlo);
return $stmh->execute() ? $stmh : undef;
}
my %attr=(
PrintError => 1,
RaiseError => 0
);
my
$dtbhÛI->connect('dbi:PgPP:dbname=miggum;host=localhost;portT32','postgres','xxxxxxxx',%attr);
if (defined $dtbh) {
my $stm1=sql($dtbh,"select oid,dmesg,delta from cal");
while (my ($oid,$dmesg,$delta)=$stm1->fetchrow_array())
{
print "$oid,$dmesg,$deltan";
my $stm2=sql($dtbh,"select oid,prgrm from pst where
dmesg='$dmesg'");
#my $stm2=$dtbh->prepare("select oid,prgrm from pst where
dmesg='$dmesg'");
#$stm2->execute();
while (my ($oid,$prgrm)=$stm2->fetchrow_array())
{
print "$oid,$prgrmn";
}
}
$dtbh->disconnect();
}
Peut-on à partir d'une même connexion DBI effectuer 2 parcours fetchrow_array imbriqués (sur 2 requêtes select) ?
A condition d'utiliser deux "statement handles" (habituellement appelé $sth, le retour de $dbh->prepare(...), utilisé pour faire le $sth->execute(...) et le $sth->fetchrow_array):
my $sth = $dbh->prepare("SELECT id FROM table1"); $sth->execute(); while (my ($id1) = $sth->fetchrow_array()) { print "table 1 id = $id1n";
my $sth2 = $dbh->prepare("SELECT id FROM table2 WHERE ref=?"); $sth->execute($id1); while (my ($id2) = $sth->fetchrow_array()) { print " table 2 id = $id2n"; } }
Sinon on peut aussi utiliser selectall_arrayref:
my $id1s = $dbh->selectall_arrayref("SELECT id FROM table1"); die if !$id1s; for my $id1 (@$id1s) { print "table 1 id = $id1n";
my $id2s = $dbh->selectall_arrayref("SELECT id FROM table2 WHERE ref=?",undef,$id1); next if !$id2s; for my $id2 (@$id2s) { print " table 2 id = $id2n"; } }
Bien entendu, dans certains cas il peut être plus efficace de combiner les deux requêtes avec une jointure SQL, mais ça dépend beaucoup de ce qu'on cherche à faire...
Jacques.
Bonjour, Merci pour cette réponse. En fait, j'ai réalisé le code ci-après. La variante, en commentaire, consiste à faire le prepare/execute sans employer la fonction "sql". Au début, je pensais que c'était elle posait problème... (dans le genre retourne la même référence pour les 2 exécute). Et ça ne marche toujours pas : après l'exécution de la seconde requête, j'ai une erreur DBI sur le nombre d'éléments lors de l'exécution du $stm1=sql($dtbh,"select oid,dmesg,delta from cal");
J'utilise : - ActivePerl 5.8.7 - DBD-PgPP 0.4.0.0 - DBI 1.48 Ah, j'oubliais... dernier détail : je suis sous Linux Gentoo 2004.3. (Mais j'ai fait un test sous Windows avec les mêmes version et j'obtiens le même résultat... :/ )
#!/usr/bin/perl -w use strict; use warnings; use DBI;
sub sql { my $dtbh=shift; my $sqlo=shift; print $sqlo . "n"; my $stmh=$dtbh->prepare($sqlo); return $stmh->execute() ? $stmh : undef; }
my %attr=( PrintError => 1, RaiseError => 0 );
my $dtbhÛI->connect('dbi:PgPP:dbname=miggum;host=localhost;portT32','postgres','xxxxxxxx',%attr); if (defined $dtbh) { my $stm1=sql($dtbh,"select oid,dmesg,delta from cal"); while (my ($oid,$dmesg,$delta)=$stm1->fetchrow_array()) { print "$oid,$dmesg,$deltan"; my $stm2=sql($dtbh,"select oid,prgrm from pst where dmesg='$dmesg'");
#my $stm2=$dtbh->prepare("select oid,prgrm from pst where dmesg='$dmesg'"); #$stm2->execute();
while (my ($oid,$prgrm)=$stm2->fetchrow_array()) { print "$oid,$prgrmn"; } } $dtbh->disconnect(); }
-- Cordialement, Jean-Marc "j!hem" QUERE
Jacques Caron
Salut,
On Sat, 04 Feb 2006 11:08:58 +0100, j!hem <[nospam] wrote:
- DBD-PgPP 0.4.0.0
C'est peut-être ça le problème? Pourquoi ne pas utiliser DBD-Pg?
Sinon la méthode du selectall_arrayref permet d'éviter le problème...
Jacques. -- Oxado http://www.oxado.com/
Salut,
On Sat, 04 Feb 2006 11:08:58 +0100, j!hem <[nospam]quere.jmarc@wanadoo.fr>
wrote:
- DBD-PgPP 0.4.0.0
C'est peut-être ça le problème? Pourquoi ne pas utiliser DBD-Pg?
Sinon la méthode du selectall_arrayref permet d'éviter le problème...
On Sat, 04 Feb 2006 11:08:58 +0100, j!hem <[nospam] wrote:
- DBD-PgPP 0.4.0.0
C'est peut-être ça le problème? Pourquoi ne pas utiliser DBD-Pg?
Sinon la méthode du selectall_arrayref permet d'éviter le problème...
Jacques. -- Oxado http://www.oxado.com/
j!hem
Jacques Caron a émis l'idée suivante :
Salut,
On Sat, 04 Feb 2006 11:08:58 +0100, j!hem <[nospam] wrote:
- DBD-PgPP 0.4.0.0
C'est peut-être ça le problème? Pourquoi ne pas utiliser DBD-Pg?
Sinon la méthode du selectall_arrayref permet d'éviter le problème...
Jacques.
Bonjour, Bien vu, c'est le pilote qui plante... J'avais pris le premier trouvé (DBD-PgPP) et ne savais pas qu'il y en avait plusieurs (quelle drôle d'idée ?!). Merci pour tout. :-) Cordialement, Jean-Marc QUERE
-- Cordialement, Jean-Marc "j!hem" QUERE
Jacques Caron a émis l'idée suivante :
Salut,
On Sat, 04 Feb 2006 11:08:58 +0100, j!hem <[nospam]quere.jmarc@wanadoo.fr>
wrote:
- DBD-PgPP 0.4.0.0
C'est peut-être ça le problème? Pourquoi ne pas utiliser DBD-Pg?
Sinon la méthode du selectall_arrayref permet d'éviter le problème...
Jacques.
Bonjour,
Bien vu, c'est le pilote qui plante... J'avais pris le premier trouvé
(DBD-PgPP) et ne savais pas qu'il y en avait plusieurs (quelle drôle
d'idée ?!). Merci pour tout. :-)
Cordialement,
Jean-Marc QUERE
On Sat, 04 Feb 2006 11:08:58 +0100, j!hem <[nospam] wrote:
- DBD-PgPP 0.4.0.0
C'est peut-être ça le problème? Pourquoi ne pas utiliser DBD-Pg?
Sinon la méthode du selectall_arrayref permet d'éviter le problème...
Jacques.
Bonjour, Bien vu, c'est le pilote qui plante... J'avais pris le premier trouvé (DBD-PgPP) et ne savais pas qu'il y en avait plusieurs (quelle drôle d'idée ?!). Merci pour tout. :-) Cordialement, Jean-Marc QUERE
-- Cordialement, Jean-Marc "j!hem" QUERE
Jacques Caron
Salut,
On Sun, 05 Feb 2006 13:44:48 +0100, j!hem <[nospam] wrote:
Bien vu, c'est le pilote qui plante... J'avais pris le premier trouvé (DBD-PgPP) et ne savais pas qu'il y en avait plusieurs (quelle drôle d'idée ?!).
PgPP est "pure perl", il n'a pas besoin des librairies de PostgresSQL (libpq...), donc il peut être utilisé sur n'importe quelle plate-forme où on peut utiliser perl, que PostgreSQL y ait été porté ou pas. Pas besoin non plus d'installer les librairies en question, ça peut simplifier la tâche si on veut déployer un client Windows qui attaque un serveur PostgreSQL sur une autre machine, par exemple. Mais il a visiblement quelques limitations...
Jacques. -- Oxado http://www.oxado.com/
Salut,
On Sun, 05 Feb 2006 13:44:48 +0100, j!hem <[nospam]quere.jmarc@wanadoo.fr>
wrote:
Bien vu, c'est le pilote qui plante... J'avais pris le premier trouvé
(DBD-PgPP) et ne savais pas qu'il y en avait plusieurs (quelle drôle
d'idée ?!).
PgPP est "pure perl", il n'a pas besoin des librairies de PostgresSQL
(libpq...), donc il peut être utilisé sur n'importe quelle plate-forme où
on peut utiliser perl, que PostgreSQL y ait été porté ou pas. Pas besoin
non plus d'installer les librairies en question, ça peut simplifier la
tâche si on veut déployer un client Windows qui attaque un serveur
PostgreSQL sur une autre machine, par exemple. Mais il a visiblement
quelques limitations...
On Sun, 05 Feb 2006 13:44:48 +0100, j!hem <[nospam] wrote:
Bien vu, c'est le pilote qui plante... J'avais pris le premier trouvé (DBD-PgPP) et ne savais pas qu'il y en avait plusieurs (quelle drôle d'idée ?!).
PgPP est "pure perl", il n'a pas besoin des librairies de PostgresSQL (libpq...), donc il peut être utilisé sur n'importe quelle plate-forme où on peut utiliser perl, que PostgreSQL y ait été porté ou pas. Pas besoin non plus d'installer les librairies en question, ça peut simplifier la tâche si on veut déployer un client Windows qui attaque un serveur PostgreSQL sur une autre machine, par exemple. Mais il a visiblement quelques limitations...
Jacques. -- Oxado http://www.oxado.com/
j!hem
Le 05/02/2006, Jacques Caron a supposé :
Salut,
On Sun, 05 Feb 2006 13:44:48 +0100, j!hem <[nospam] wrote:
Bien vu, c'est le pilote qui plante... J'avais pris le premier trouvé (DBD-PgPP) et ne savais pas qu'il y en avait plusieurs (quelle drôle d'idée ?!).
PgPP est "pure perl", il n'a pas besoin des librairies de PostgresSQL (libpq...), donc il peut être utilisé sur n'importe quelle plate-forme où on peut utiliser perl, que PostgreSQL y ait été porté ou pas. Pas besoin non plus d'installer les librairies en question, ça peut simplifier la tâche si on veut déployer un client Windows qui attaque un serveur PostgreSQL sur une autre machine, par exemple. Mais il a visiblement quelques limitations...
Jacques.
Merci pour ces précisions utiles. Me voilà remis en selle (jusqu'à la prochaine fois ;-) )
-- Cordialement, Jean-Marc "j!hem" QUERE
Le 05/02/2006, Jacques Caron a supposé :
Salut,
On Sun, 05 Feb 2006 13:44:48 +0100, j!hem <[nospam]quere.jmarc@wanadoo.fr>
wrote:
Bien vu, c'est le pilote qui plante... J'avais pris le premier trouvé
(DBD-PgPP) et ne savais pas qu'il y en avait plusieurs (quelle drôle d'idée
?!).
PgPP est "pure perl", il n'a pas besoin des librairies de PostgresSQL
(libpq...), donc il peut être utilisé sur n'importe quelle plate-forme où on
peut utiliser perl, que PostgreSQL y ait été porté ou pas. Pas besoin non
plus d'installer les librairies en question, ça peut simplifier la tâche si
on veut déployer un client Windows qui attaque un serveur PostgreSQL sur une
autre machine, par exemple. Mais il a visiblement quelques limitations...
Jacques.
Merci pour ces précisions utiles. Me voilà remis en selle (jusqu'à la
prochaine fois ;-) )
On Sun, 05 Feb 2006 13:44:48 +0100, j!hem <[nospam] wrote:
Bien vu, c'est le pilote qui plante... J'avais pris le premier trouvé (DBD-PgPP) et ne savais pas qu'il y en avait plusieurs (quelle drôle d'idée ?!).
PgPP est "pure perl", il n'a pas besoin des librairies de PostgresSQL (libpq...), donc il peut être utilisé sur n'importe quelle plate-forme où on peut utiliser perl, que PostgreSQL y ait été porté ou pas. Pas besoin non plus d'installer les librairies en question, ça peut simplifier la tâche si on veut déployer un client Windows qui attaque un serveur PostgreSQL sur une autre machine, par exemple. Mais il a visiblement quelques limitations...
Jacques.
Merci pour ces précisions utiles. Me voilà remis en selle (jusqu'à la prochaine fois ;-) )
