Discussion :

[julien43120]

Bonjour,
Et me revoilà deja . . .

Hier j'ai travaillé sur la base mysql que je viens de créé, et j'ai un souci pour exporter
une variable vers ma bdd. J'ai créé la requete qui va bien et j'ai un souci dans celle-ci.

Voilà, j'ai une adresse IP qui me sert dans ma sub start_onnection et je veux l'exporter dans ma bdd.

[CODE] my $connection = start_connection($_); => Besoin de la valeur située ici dans $_
my $dbh = start_connection_sql($_);
next unless ($connection);
my %values = get_values($connection, %params);

# log_write(%values);
end_connection($connection);


#foreach (@servers)

my $query = sprintf 'INSERT INTO Puissance(ID_Compteur) VALUES ("'.($_).'" )'; => besoin ici
print("\n $query \n");
[\CODE]

Le problème c'est que cela ne fonctionne pas, j'ai testé pas mal de synthaxe et impossible d'avancer

Merci pour votre aide.
@+

[julien43120]

En fait, grosse erreur de ma part,
J'ai mal recopié le truc j'avais marqué _$ au lieu de $_ erreur humaine lol.

Parcontre en lancant la requete, j'ai ces erreurs :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
 
##### ouverture session #####
 
 
Content-type: text/htmlnnDBD::mysql::st execute failed: Duplicate entry '172.17.
14.17' for key 'PRIMARY' at F:/export_data_sql_V7.pl line 297.
DBD::mysql::st execute failed: Duplicate entry '' for key 'PRIMARY' at F:/export
_data_sql_V7.pl line 310.
DBD::mysql::st execute failed: Duplicate entry '' for key 'PRIMARY' at F:/export
_data_sql_V7.pl line 317.
Content-type: text/htmlnnDBD::mysql::st execute failed: Duplicate entry '172.17.
14.5' for key 'PRIMARY' at F:/export_data_sql_V7.pl line 297.
DBD::mysql::st execute failed: Duplicate entry '' for key 'PRIMARY' at F:/export
_data_sql_V7.pl line 310.
DBD::mysql::st execute failed: Duplicate entry '' for key 'PRIMARY' at F:/export
_data_sql_V7.pl line 317.
Content-type: text/htmlnnDBD::mysql::st execute failed: Duplicate entry '172.17.
14.3' for key 'PRIMARY' at F:/export_data_sql_V7.pl line 297.
DBD::mysql::st execute failed: Duplicate entry '' for key 'PRIMARY' at F:/export
_data_sql_V7.pl line 310.
DBD::mysql::st execute failed: Duplicate entry '' for key 'PRIMARY' at F:/export
_data_sql_V7.pl line 317.
 
 
 
##### Fin session #####
Press Enter to continue

J'ai cherche, mais pas trouvé de réponses claires à mes questions . . .

Merci pour vore aide.
@+

[dmganges]

Salut

Bon je fais comme si je découvrais, pas pour faire l'âne là je n'ai pas besoin de me forcer, mais parce que j'interviens sur plusieurs sujets et que ma mémoire se réduit à une peau de chagrin.

Code :

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

Content-type: text/htmlnnDBD::mysql::st execute failed: Duplicate entry '172.17. 14.17' for key 'PRIMARY' at F:/export_data_sql_V7.pl line 297.

Le message est clair :
Sur la table sur laquelle tu fais un INSERT il y a déjà une ligne dans la table qui à pour valeur de PRIMARY KEY '172.17. 14.17'
Lorsque dans le schéma d'une base de donnée on déclare une colonne comme étant la CLÉ PRIMAIRE de la table, cela veut dire que l'information contenue dans cette colonne permettra d'accéder à UNE et UNE SEULE ligne de la table.
A la CLÉ PRIMAIRE est associé un INDEX qui veille au grain, une sorte de gendarme qui interdit les doublons

Si au moment de l'INSERT le SGBG ( Le Système de Gestion de la Base de Donnée) détecte qu'il existe déjà dans la table une ligne avec cette CLE ici : "172.17. 14.17" il refuse tout bonnement !!!

Car s'il acceptait, un SELECT avec par exemple '172.17. 14.17' comme clé, il ramènerait plusieurs lignes de la table...

Donc les données de ton fichier en entrée ne sont pas TOUTES compatibles

- Soit c'est une erreur grave (insupportable pour l'avenir des traitements réalisés sur la base) et dès qu'une telle erreur se produit tu fais un print de la requête ($query) pour mieux comprendre... et un exit du programme
- Soit tu considères que l'information : la ligne qui existe déjà dans la table, avec par exemple ''172.17. 14.17", est convenable et SUFFISANTE, et tu passes au traitement de l’enregistrement suivant...

Personne ne pourra prendre la décision à ta place.

Il y a sur devellopez un forum dédié à MySQL et certainement plein de tutos pour démarrer et comprendre.
Sauf si ce que tu exposes ici n'est qu'un besoin spécifique et limité, je te conseille d'acquérir un minimum de connaissance sur les bases de données...

[julien43120]

Ok, je vauis donc suivre un tuto pour voir l'erreur et voir comment la corriger.

Parsque en fait, lors de mon export, j'ai 3 serveurs qui me renvoient une valeur.
Ensuite, je viens lire ses valeurs et els exporter dans ma Bdd à travers ces requetes.

Suis-je obliger de mettre quelque chose dans la clé primaire ? ou pas ? à chaque export.

Je regarde les tuto.

Merci
@+

[dmganges]

Parsque en fait, lors de mon export, j'ai 3 serveurs qui me renvoient une valeur.

Je ne sais pas comment s'effectue le traitement en amont, mais imagine :

Si chacun des serveurs crée un enregistrement dans le fichier que tu utilises pour charger la table, avec '172.17. 14.17' comme information susceptible d'accéder à un SEUL enregistrement,
au bout du compte ça t'en fait trois :

'172.17. 14.17','TOTO',....SERVEUR_1
'172.17. 14.17','TITI',....SERVEUR_2
'172.17. 14.17','TATA'....SERVEUR_3
Le premier sera accepté dans la table, les deux suivants NON

Donc à la construction de la table (CREATE) cette colonne ne peut pas être déclarée PRIMARY KEY

Dans une BDD bien construite chaque table devrait avoir une PRIMARY KEY, je ne sais pas si MySQL accepte une table sans PRIMARY KEY

Dans le cas contraire, le CREATE de la table doit prévoir une colonne supplémentaire qui en fait ne voudra pas dire grand chose pour toi...
Cette colonne supplémentaire sera associé à un COMPTEUR qui s'incrémente de 1 à chaque ajout de ligne, ainsi tu auras bien une colonne qui, au moins théoriquement, permettrait l'accès à UNE SEULE ligne.

Ensuite rien ne t'empêche d'ajouter un index sur la colonne qui contient les adresses IP, mais cet index ne pourra pas être un INDEX UNIQUE, puisqu'il devra pouvoir accepter des doublons...

Suis-je obliger de mettre quelque chose dans la clé primaire ?

Ben maintenant tu as la réponse : OUI

Sinon cela équivaudrait à avoir deux lignes avec adresse IP identique = ''
Donc pas bon !

Dans une table la colonne qui sert de clé primaire doit toujours être renseignée !

[julien43120]

Ok, merci bien.
J'ai trouvé quelques réponses dans les tuto (bien faits en plus ^^)

Du coup, je refaits ma bdd avec :

Table 1
1 clé primaire id qui va s'auto incrémenter
2 adresse_IP
3 puissancep
4 puissanceq
5 datetime

Table 2
1 clé primaire id qui va s'auto incrémenter
2 nom_compteur
3 lieu

Et comme sa, a chaque export de données, une nouvelle id est créée, et mes données pouront se rajouter dans ma bdd.

J'avais un problème sur la clé primaire, je ne connaissais pas le role exactement.

Merci
@+

[dmganges]

De rien

Sur le forum MySQL ou d'autres, recherche des articles qui expliquent la théorie des BDD.
Il n'y à rien de compliqué, sinon je n'y serait jamais arrivé, mais ce n'est pas inné non plus.

Les performances d'une BDD sont directement liées à sa construction, d'autant plus que le volume de donnée est important...
Mentalement, estime le volume des BDD de Google par exemple et le temps de réponse !!!

Seules des bases biens construites permettent de telles performances...
Bien sûr si ta table ne contient que quelques centaines voire quelques milliers de lignes tu peux faire l'impasse...

Mais c'est comme au BAC, si un jour le volume des données exploses, t'es bon pour le repêchage

Fais des recherches sur NORMALISATION DES BDD RELATIONNELLES
Si tu ne mets pas tout en œuvre, tu pourras au moins te faire une idée...

[dmganges]

PS n'abuse pas des compteurs auto incrémentés !
Il est bien rare qu'il n'y ait pas une information qui puisse servir de clé primaire !

Tu dois te poser la question avant :
Si tu n'as que des compteurs auto incrémentés comment retrouveras-tu une information ?

Une requête qui ne pourra que te ramener systématiquement plusieurs lignes, sera une galère plus tard en SELECT SQL...