[sgbd] Recuperer valeurs d'un Select dans un tableau

Version imprimable

Salut à tous ( oui c'est encore moi :D ),

je voudrais recuperer toutes les valeurs d'un Select dans un tableau, sans afficher les lignes.
J'ai essaye cette ligne mais en vain :
Code:

1 2 3 4 5 6 7 8 $sth = $dbh -> prepare("select * from matable LIMIT 10") or die "Impossible de preparer : ". $dbh->errstr()."\n"; $sth->execute(); while ($a = $sth->fetchrow_array ) { push (@ip,$a); } print "@ip\n";
@+

Chez moi, ce code ci-dessous fonctionne parfaitement :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
$sth = $dbh->prepare("select * from TABLE where ID = 1,2,3,4,5");
$sth->execute();
if ($DBI::errstr)
{
	warn "err sur req SQL : $DBI::errstr\n";
} else {
	while (@_ = $sth->fetchrow_array)
	{
	    $hash{$_[0]}->{CHAMP1} = $_[0];
	    $hash{$_[0]}->{CHAMP2} = $_[1];
	    $hash{$_[0]}->{CHAMP3} = $_[2];
	}
}

08/06/2004, 11h18
Mu_Belier
J'ai rajoute ca pour afficher ce que contien le hash mais il n'y a que des lignes vides :
Code:

1 2 3 4 foreach ( keys %hash ) { print "$hash->{$_}\n"; }
Es ce qu'il faut remplacer les champ1, 2 et 3 par quelque chose dans :
Code:

1 2 3 $hash{$_[0]}->{CHAMP1} = $_[0]; $hash{$_[0]}->{CHAMP2} = $_[1]; $hash{$_[0]}->{CHAMP3} = $_[2];
@+
08/06/2004, 11h24
Arioch
Citation:
Envoyé par Mu_Belier

J'ai rajoute ca pour afficher ce que contien le hash mais il n'y a que des lignes vides :

Code:

1 2 3 4 foreach ( keys %hash ) { print "$hash->{$_}\n"; }
C'est normal car toi tu as utilisé une référence vers un hash dans ton exemple tandis que moi, j'utilise un hash tout court :wink:

Essaie ça pour voir :
Code:

1 2 3 4 5 6 foreach ( keys %hash ) { print "$hash{$_}->{CHAMP1}\n"; print "$hash{$_}->{CHAMP2}\n"; print "$hash{$_}->{CHAMP3}\n"; }
08/06/2004, 12h07
Mu_Belier

Yeah ca marche, merci beaucoup.

Je suppose ke CHAMP1 , 2 , 3 , ..., correspondent au champs de ma table.
Mais est il possible de les appeler par leur vrai nom ???

@+
08/06/2004, 12h16
Arioch

Citation:

Envoyé par Mu_Belier

Yeah ca marche, merci beaucoup.

Je suppose ke CHAMP1 , 2 , 3 , ..., correspondent au champs de ma table.
Mais est il possible de les appeler par leur vrai nom ???

@+

Bien sûr, CHAMP1 etc. étaient des noms de champ dans mon exemple :wink:
08/06/2004, 12h20
Arioch

Et dans mon exemple, chaque clé que j'utilise dans mon hash correspond au n° de l'enregistrement (ID ou une clé, enfin une valeur numérique qui soit unique pour chaque enregistrement de ta table). Ainsi, ton hash devient ni + ni - qu'une pseudo table :D
08/06/2004, 12h34
Mu_Belier

Ah d'accord, pourtant j'ai mis les memes que dans ton exemple et ca a marche :lol: .

Un grand merci a toi pour ces reponses, je reviendrais surement pour d'autres questions :twisted: .
08/06/2004, 12h36
Arioch

Citation:

Envoyé par Mu_Belier

Ah d'accord, pourtant j'ai mis les memes que dans ton exemple et ca a marche :lol: .

Arf, j'avais pas compris le sens de ta question. C'est à toi d'indiquer le nom des champs que te retourne ta BDD, elle ne te retourne pas les noms de champs d'elle même, voilà pourquoi ça marchait bien avec CHAMP1 etc.

Par contre, le + clair à mon sens est de nommer tes sous clés de ton hash avec les mêmes libellés, plus pratique ensuite.
08/06/2004, 12h46
Mu_Belier

Citation:

Envoyé par Arioch

Par contre, le + clair à mon sens est de nommer tes sous clés de ton hash avec les mêmes libellés, plus pratique ensuite.

D'accord, c'est noté. Merci beaucoup :wink:
27/05/2005, 13h42
YanK

Je relance ce thread, car il m'intéresse.
N'y a t-il pas moyen de récupérer un Hash directement avec le module DBI?
Ou au moins d'arriver à récupérer les noms des champs dans le même ordre que le tableau de réponse. Car si la table subit un changement il peut y avoir des décalage de résultat.
Ex:
Table1 (Champ1, Champ2, Champ3);
Devient :
Table1 (Champ0, Champ1, Champ2, Champ3);

Du coup tous les champs seront décalés et il faudra modifier le code pour éviter des erreurs. Pas très pratique.
Il doit bien exister une solution, non?
27/05/2005, 13h46
Gamdwin

Ca ne devrait pas arriver sauf si, bien sûr, tu fais des "select * from ...".

Dans ce cas là, il vaut mieux soit stocker dans un tableau soit, si tu désires réellement un hâchage, aller chercher auparavant la liste des champs de la table d'une façon ou d'une autre (sous Sybase, par exemple, ça se fait en tapant dans sysobjets et syscolumns).
27/05/2005, 13h54
YanK

Oui c'est vrai que j'ai tendance à faire des "select * from ..." :oops:
Une mauvaise habitude que je devrais perdre alors. :)
C'est quand même fastidieux de se taper tous les champs à la main. :(
27/05/2005, 13h58
Gamdwin

C'est peut-être fastidieux, mais c'est fiable.
Par définition, si ton programme fonctionne pour une table avec une certaine liste de champs, on peut ensuite ajouter autant de champs qu'on veut à cette table, et ça fonctionne toujours.
Au final, c'est rébarbatif, mais ça économise beaucoup de temps de maintenance et surtout de mauvaises surprises (effets de bords qu'on oublie d'évaluer sur une modification d'apparence anodine d'une table, ça peut coûter cher).
27/05/2005, 14h07
YanK

Oui c'est sur, mais dommage que DBI ne sorte pas un hash de résultat, car ça rendrait le code plus lisible. Au lieu de "$result[0]" on aurait "$result{'monChamp'}".
Ca serait plus compréhensible et éviterait aussi le problème de nouveaux champs décalant les autres.
J'ai du mal à faire un choix permettant d'avoir une programmation simple tout en restant souple aux changements. :)
27/05/2005, 15h37
Gamdwin

En fait, c'est possible, grace à DBI::fetchrow_hashref().

Mais c'est bien plus lent que la méthode de base, forcément, et puis à part pour quelques spécifiques (si tu dois créer un script qui se doit d'être générique, par exemple), ce n'est quand même pas conseillé de faire des "select *"

A toi de voir. ;)
27/05/2005, 15h46
YanK

Oui c'est sur. Dur dur de faire des choix qui conviennent le mieux pour la prog. :)
J'ai opté pour ne pas faire de "select *", ça sera le mieux je pense. ;)

Fuseau horaire GMT +2. Il est actuellement 20h10.