Discussion :

[Mu_Belier]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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";

@+

[Arioch]

Chez moi, ce code ci-dessous fonctionne parfaitement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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];
	}
}

[Mu_Belier]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$hash{$_[0]}->{CHAMP1} = $_[0]; 
$hash{$_[0]}->{CHAMP2} = $_[1]; 
$hash{$_[0]}->{CHAMP3} = $_[2];

@+

[Arioch]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Essaie ça pour voir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
foreach ( keys %hash )
{
        print "$hash{$_}->{CHAMP1}\n";
        print "$hash{$_}->{CHAMP2}\n";
        print "$hash{$_}->{CHAMP3}\n";
}

[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 ???

@+

[Arioch]

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

[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

[Mu_Belier]

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

Un grand merci a toi pour ces reponses, je reviendrais surement pour d'autres questions .

[Arioch]

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

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.

[Mu_Belier]

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

[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?

[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).

[YanK]

Oui c'est vrai que j'ai tendance à faire des "select * from ..."
Une mauvaise habitude que je devrais perdre alors.
C'est quand même fastidieux de se taper tous les champs à la main.

[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).

[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.

[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.

[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.