Discussion :

[spip93]

Bonjour à tous et à toutes,

Je voudrais mettre à jour une table ps_product d'un site sous Prestashop (v 1.6.1.16). J'utilise donc la requête UPDATE.

Voici ce que je mets pour la 1ère ligne/1er enregistrement :

Code :

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

UPDATE ps_product SET id_product = '10', id_supplier = '0', id_manufacturer = '3', id_category_default = '15', id_shop_default = '1', id_tax_rules_group = '1', on_sale = '0', online_only = '0', ean13 = '8712026021991', upc = '', ecotax = '0.000000', quantity = '0', minimal_quantity = '1', price = '18.330000', wholesale_price = '0.000000', unity = '', unit_price_ratio = '0.000000', additional_shipping_cost = '0.00', reference = '87077/02101-87079', supplier_reference = '87077/02101', location = '', width = '0.000000', height = '0.000000', depth = '0.000000', weight = '0.000000', out_of_stock = '2', quantity_discount = '0', customizable = '0', uploadable_files = '0', text_fields = '0', active = '1', redirect_type = '404', id_product_redirected = '0', available_for_order = '1', available_date = '0000-00-00', condition = 'new', show_price = '1', indexed = '1', visibility = 'both', cache_is_pack = '0', cache_has_attachments = '0', is_virtual = '0', cache_default_attribute = '400', date_add = '2016-08-08 10:35:09', date_upd = '2017-12-21 16:19:34', advanced_stock_management = '0', pack_stock_type = '3' WHERE id_product = 10;

Le problème c'est que j'ai cet ensemble d'erreurs :

Analyse statique :

47 erreurs trouvées lors de l'analyse.

Mot clé non reconnu. (near "condition" at position 820)
Jeton inattendu. (near "=" at position 830)
Jeton inattendu. (near "'new'" at position 832)
Jeton inattendu. (near "," at position 837)
Jeton inattendu. (near "show_price" at position 839)
Jeton inattendu. (near "=" at position 850)
Jeton inattendu. (near "'1'" at position 852)
Jeton inattendu. (near "," at position 855)
Jeton inattendu. (near "indexed" at position 857)
Jeton inattendu. (near "=" at position 865)
Jeton inattendu. (near "'1'" at position 867)
Jeton inattendu. (near "," at position 870)
Jeton inattendu. (near "visibility" at position 872)
Jeton inattendu. (near "=" at position 883)
Jeton inattendu. (near "'both'" at position 885)
Jeton inattendu. (near "," at position 891)
Jeton inattendu. (near "cache_is_pack" at position 893)
Jeton inattendu. (near "=" at position 907)
Jeton inattendu. (near "'0'" at position 909)
Jeton inattendu. (near "," at position 912)
Jeton inattendu. (near "cache_has_attachments" at position 914)
Jeton inattendu. (near "=" at position 936)
Jeton inattendu. (near "'0'" at position 938)
Jeton inattendu. (near "," at position 941)
Jeton inattendu. (near "is_virtual" at position 943)
Jeton inattendu. (near "=" at position 954)
Jeton inattendu. (near "'0'" at position 956)
Jeton inattendu. (near "," at position 959)
Jeton inattendu. (near "cache_default_attribute" at position 961)
Jeton inattendu. (near "=" at position 985)
Jeton inattendu. (near "'400'" at position 987)
Jeton inattendu. (near "," at position 992)
Mot clé non reconnu. (near "date_add" at position 994)
Jeton inattendu. (near "=" at position 1003)
Jeton inattendu. (near "'2016-08-08 10:35:09'" at position 1005)
Jeton inattendu. (near "," at position 1026)
Jeton inattendu. (near "date_upd" at position 1028)
Jeton inattendu. (near "=" at position 1037)
Jeton inattendu. (near "'2017-12-21 16:19:34'" at position 1039)
Jeton inattendu. (near "," at position 1060)
Jeton inattendu. (near "advanced_stock_management" at position 1062)
Jeton inattendu. (near "=" at position 1088)
Jeton inattendu. (near "'0'" at position 1090)
Jeton inattendu. (near "," at position 1093)
Jeton inattendu. (near "pack_stock_type" at position 1095)
Jeton inattendu. (near "=" at position 1111)
Jeton inattendu. (near "'3'" at position 1113)

Requête SQL :

UPDATE prsts_product SET id_product = '10', id_supplier = '0', id_manufacturer = '3', id_category_default = '15', id_shop_default = '1', id_tax_rules_group = '1', on_sale = '0', online_only = '0', ean13 = '8712026021991', upc = '', ecotax = '0.000000', quantity = '0', minimal_quantity = '1', price = '18.330000', wholesale_price = '0.000000', unity = '', unit_price_ratio = '0.000000', additional_shipping_cost = '0.00', reference = '87077/02101-87079', supplier_reference = '87077/02101', location = '', width = '0.000000', height = '0.000000', depth = '0.000000', weight = '0.000000', out_of_stock = '2', quantity_discount = '0', customizable = '0', uploadable_files = '0', text_fields = '0', active = '1', redirect_type = '404', id_product_redirected = '0', available_for_order = '1', available_date = '0000-00-00', condition = 'new', show_price = '1', indexed = '1', visibility = 'both', cache_is_pack = '0', cache_has_attachments = '0', is_virtual = '0', cache_default_attribute = '400', date_add = '2016-08-08 10:35:09', date_upd = '2017-12-21 16:19:34', advanced_stock_management = '0', pack_stock_type = '3' WHERE id_product = 10

MySQL a répondu : Documentation
#1064 - Erreur de syntaxe près de 'condition = 'new', show_price = '1', indexed = '1', visibility = 'both', cache_i' à la ligne 1

Je ne comprends d'autant pas, que je me suis basé sur la requête suivante (appliquée à une autre table) et qui, elle, fonctionne :

Code :

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

UPDATE ps_product_attribute SET reference = '87143M', ean13 = '8712026871435' WHERE id_product_attribute = 15;

Est-ce que vous sauriez pourquoi ça ne fonctionne pas ? Que signifie "Jeton inattendu" ?

D'avance merci pour vos réponses.

Bonne journée

[CinePhil]

Comme c'est juste avant l'erreur, peut-être que c'est ça qui coince :

Code :

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

available_date = '0000-00-00'

Essayez avec available_date = NULL

[spip93]

Merci CinéPhil, mais malheureusement, ça n'a pas fonctionné

[spip93]

Je viens de trouver !
Dans ma table, j'ai une colonne intitulée "condition". Ça devait faire conflit avec MySQL parce que je l'ai enlevée et maintenant ça fonctionne.
D'autre part, je n'ai pas tout de suite vu, mais le mot "condition" était de couleur violette comme "UPDATE" et "WHERE".
Ce qui est quand même mal fait, c'est que :
1) Un mot (en l'occurrence "condition") provoque 47 erreurs
2) Ça indique "jeton inattendu" à la place de quelque chose comme "conflit"...

J'espère que ma mésaventure servira à d'autres qui ont le même problème.
Bonne soirée et bonnes fêtes à tous.

[bstjean]

1) "condition" est un mot réservé en MySQL, donc à proscrire pour éviter les maux de tête. Cependant, si tu tiens absolument à l'utiliser, tu peux le mettre entre backticks. Pour les mots réservés, voir ici (https://dev.mysql.com/doc/refman/5.7/en/keywords.html)
2) Ta requête est affreusement inefficace comme tu utilises *partout* des strings au lieu du type de la colonne! Par exemple, je doute fortement que id_product soit déclaré comme VARCHAR dans ta table! Ça force MySQL à convertir chaque valeur dans le type avec lequel la colonne a été déclarée!

[spip93]

1) "condition" est un mot réservé en MySQL, donc à proscrire pour éviter les maux de tête. Cependant, si tu tiens absolument à l'utiliser, tu peux le mettre entre backticks.

En l'occurrence, ça n'est pas moi qui ait décidé d'attribuer "condition" à une entête, c'est Prestashop. Mais merci pour le conseil

2) Ta requête est affreusement inefficace comme tu utilises *partout* des strings au lieu du type de la colonne! Par exemple, je doute fortement que id_product soit déclaré comme VARCHAR dans ta table! Ça force MySQL à convertir chaque valeur dans le type avec lequel la colonne a été déclarée!

J'entends, pas de soucis. Cependant, je n'ai fait qu'adapter, à ma table, une requête UPDATE car je suis un grand débutant en SQL.
Qu'est-ce que je devrais mettre quand c'est le type :

• int(10)
• tinyint(1)
• decimal(20,6)
• date

pour que ma requête soit efficace.

Ça force MySQL à convertir chaque valeur dans le type avec lequel la colonne a été déclarée!

C'est grave docteur ?

Merci pour ta réponse.
Bonne journée et bonnes fêtes

[Artemus24]

Salut spip93.

Voici votre requête mise en forme :

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
UPDATE  ps_product
   SET  id_product                = '10',
        id_supplier               = '0',
        id_manufacturer           = '3',
        id_category_default       = '15',
        id_shop_default           = '1',
        id_tax_rules_group        = '1',
        on_sale                   = '0',
        online_only               = '0',
        ean13                     = '8712026021991',
        upc                       = '',
        ecotax                    = '0.000000',
        quantity                  = '0',
        minimal_quantity          = '1',
        price                     = '18.330000',
        wholesale_price           = '0.000000',
        unity                     = '',
        unit_price_ratio          = '0.000000',
        additional_shipping_cost  = '0.00',
        reference                 = '87077/02101-87079',
        supplier_reference        = '87077/02101',
        location                  = '',
        width                     = '0.000000',
        height                    = '0.000000',
        depth                     = '0.000000',
        weight                    = '0.000000',
        out_of_stock              = '2',
        quantity_discount         = '0',
        customizable              = '0',
        uploadable_files          = '0',
        text_fields               = '0',
        active                    = '1',
        redirect_type             = '404',
        id_product_redirected     = '0',
        available_for_order       = '1',
        available_date            = '0000-00-00',
        condition                 = 'new',
        show_price                = '1',
        indexed                   = '1',
        visibility                = 'both',
        cache_is_pack             = '0',
        cache_has_attachments     = '0',
        is_virtual                = '0',
        cache_default_attribute   = '400',
        date_add                  = '2016-08-08 10:35:09',
        date_upd                  = '2017-12-21 16:19:34',
        advanced_stock_management = '0',
        pack_stock_type           = '3'
 WHERE  id_product                = 10;

Il y a plusieurs choses qui ne vont pas :

1) quand la colonne est de type numérique, on n'affecte pas une chaîne de caractères, car cela va provoquer une conversion inutile.

2) normalement, vous devez renseigner chaque colonne. Une colonne à vide ou marquée à NULL est une erreur de conception.

3) il est désormais interdit d'utiliser les dates à '0000-00-00'.

4) il y a une redondance de la valeur '87077/02101' dans la déclarative de vos colonnes "reference" et "supplier_reference".
Cela ne sert à rien, sinon à consommer de l'espace disque pour rien.

5) votre problème est que vous utilisez comme nom de colonne, des mots réservés.
Une astuce pour éviter cela, est de les préfixer par un mot désignant la table.
Ou encore, comme le suggère "bstjean", d'utiliser l'apostrophe oblique (touche alt gr + 7) et qui donne `.

6) les colonnes "date_add" et "date_upd" sont des colonnes techniques afin de déterminer la création et la modification de la ligne.
Vous ne devez pas les modifier !

Qu'est-ce que je devrais mettre quand c'est le type :

7) pour le type "int", la valeur est un entier, donc sans virgule, allant de -2.147.483.648 à +2.147.483.647.

8) pour le type "tinyint", la valeur est aussi un entier, allant de -128 à +127.

9) pour le type "decimal(20,6)", la valeur doit être décimal, c'est-à-dire avec une virgule en fait c'est "decimal point").
Le 6 signifie que la partie décimale comprend six chiffres. Le 20 correspond au nombre maximal de chiffres dans votre nombre, soit 14 pour la partie entière de votre nombre.
Votre nombre s'écrit -125.14 et à l'affichage, vous aurez -125.140000.
--> https://dev.mysql.com/doc/refman/5.7...teristics.html

Remarque : n'utilisez pas le float ou le double pour stocker des montants comptables.

C'est grave docteur ?

Non, ce n'est pas grave, mais vous faites faire à MySql des choses inutiles, et la performance de votre requête va se ressentir.

@+

[spip93]

Voici votre requête mise en forme :

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
UPDATE  ps_product
   SET  id_product                = '10',
        id_supplier               = '0',
        id_manufacturer           = '3',
        id_category_default       = '15',
        id_shop_default           = '1',
        id_tax_rules_group        = '1',
        on_sale                   = '0',
        online_only               = '0',
        ean13                     = '8712026021991',
        upc                       = '',
        ecotax                    = '0.000000',
        quantity                  = '0',
        minimal_quantity          = '1',
        price                     = '18.330000',
        wholesale_price           = '0.000000',
        unity                     = '',
        unit_price_ratio          = '0.000000',
        additional_shipping_cost  = '0.00',
        reference                 = '87077/02101-87079',
        supplier_reference        = '87077/02101',
        location                  = '',
        width                     = '0.000000',
        height                    = '0.000000',
        depth                     = '0.000000',
        weight                    = '0.000000',
        out_of_stock              = '2',
        quantity_discount         = '0',
        customizable              = '0',
        uploadable_files          = '0',
        text_fields               = '0',
        active                    = '1',
        redirect_type             = '404',
        id_product_redirected     = '0',
        available_for_order       = '1',
        available_date            = '0000-00-00',
        condition                 = 'new',
        show_price                = '1',
        indexed                   = '1',
        visibility                = 'both',
        cache_is_pack             = '0',
        cache_has_attachments     = '0',
        is_virtual                = '0',
        cache_default_attribute   = '400',
        date_add                  = '2016-08-08 10:35:09',
        date_upd                  = '2017-12-21 16:19:34',
        advanced_stock_management = '0',
        pack_stock_type           = '3'
 WHERE  id_product                = 10;

Merci Artemus pour la mise en forme. Effectivement, c'est comme ça que je devrais le mettre dans PHPMyAdmin.
(Je me prends surement la tête, mais) En fait, je modifie mes tables sous Excel. Une fois les modifs faites, je génère une requête SQL grâce à la fonction CONCATENER. C'est pour ça que ma requête n'est pas mise en forme comme vous l'avez fait. Avec ça, je ne génère pas qu'une seule requête, mais une requête par ligne (1173 lignes en l'occurrence).
Normalement, je devrais mettre à jour uniquement les colonnes que je modifie, mais je préfère mettre à jour toute la table pour être sûr de ne rien oublier.

Quand la colonne est de type numérique, on n'affecte pas une chaîne de caractères, car cela va provoquer une conversion inutile.

En fait, c'était l'objet de ma question dans mon post précédent :

Qu'est-ce que je devrais mettre quand c'est le type init, tinyint, decimal(20,6) pour que ma requête soit efficace ?

Autrement dit, comment est-ce que j'aurais dû écrire ma requête quand le type est init, tinyint, decimal(20,6), ... ?

2) Normalement, vous devez renseigner chaque colonne. Une colonne à vide ou marquée à NULL est une erreur de conception.
3) il est désormais interdit d'utiliser les dates à '0000-00-00'.

Encore une fois, c'est pas moi qui ait décidé de faire comme ça, c'est Prestashop. J'aurais bien été incapable de faire ça tout seul

4) il y a une redondance de la valeur '87077/02101' dans la déclarative de vos colonnes "reference" et "supplier_reference".
Cela ne sert à rien, sinon à consommer de l'espace disque pour rien.

De toute façon, je n'ai rien mis pour dans les autres lignes dans la colonne "supplier_reference". Néanmoins, je suis curieux : comment est-ce que j'aurais dû écrire ma requête pour mettre à jour ces 2 colonnes si les valeurs sont redondantes ?

Merci pour vos réponses

[bstjean]

En l'occurrence, ça n'est pas moi qui ait décidé d'attribuer "condition" à une entête, c'est Prestashop. Mais merci pour le conseil

J'entends, pas de soucis. Cependant, je n'ai fait qu'adapter, à ma table, une requête UPDATE car je suis un grand débutant en SQL.
Qu'est-ce que je devrais mettre quand c'est le type :

• int(10)
• tinyint(1)
• decimal(20,6)
• date

pour que ma requête soit efficace.

C'est grave docteur ?

Merci pour ta réponse.
Bonne journée et bonnes fêtes

1) Pour *TOUS* les types numériques entiers (TINYINT, SMALLINT, MEDIUMINT, INTEGER, BIGINT), les types numériques exacts avec point fixe (DECIMAL, NUMERIC) et les types numériques avec point fixe approximatifs (FLOAT, DOUBLE), la valeur ne doit pas être entre apostrophes. Ça donne ceci

UPDATE matable SET monNumerique=22; /*au lieu de '22' */

2) Pour tous les type de date/temps (DATE, TIME, DATETIME, TIMESTAMP), la valeur doit être entre apostrophes (donc une string):

UPDATE matable SET macolonnetemporelle = '2017-12-24';

3) Évidemment, tout ce qui est de type string (CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM, SET), tout doit être entre apostrophes È

UPDATE matable SET macolonnedecaracteres = 'Joyeux Noël';

4) Tu auras donc compris qu'en résumé, quand c'est un nombre, ça ne nécessite pas d'apostrophes et ça en prend dans tous les autres cas!

5) Est-ce que c'est grave docteur? Ce n'est pas mortel mais tant qu'à faire les choses, autant le faire comme il se doit! Utiliser le mauvais type dans la déclaration d'une table, ça consomme de l'espace disque pour rien dans la table, ça consomme de l'espace disque pour rien dans l'index, ça force une conversion pour chaque enregistrement, ça t'empêche d'utiliser toutes les fonctions normalement disponibles pour "le bon type", ça réduit le nombre de pages de données que MySQL peut charger en cache, ça diminue le nombre de pages de data que MySQL peut charger dans le data buffer, ça ralentit les jointures, ça affecte la performance des "index lookup", ça réduit le nombre de pages d'index dans le buffer, ça prend plus de temps à transférer sur le réseau (par exemple 18446744073709551615 prend 8 bytes au lieu de 20 bytes pour '18446744073709551615'), ça prend plus de temps à trier, ça prend plus d'espace disque dans les tables temporaires, etc...

[Artemus24]

Salut spip93.

Merci Artemus pour la mise en forme.

Pas de quoi ! La mise en forme que j'ai proposé, c'est pour le forum, afin que la requête soit plus facilement lisible.

En fait, je modifie mes tables sous Excel.

Si vous charger vos fichiers excel dans des tables MySql, il y a plus simple que de faire des requêtes de mise à jour.
Vous devez utiliser le "LOAD DATA LOCAL INFILE".
--> https://dev.mysql.com/doc/refman/5.7/en/load-data.html

Voici un exemple de chargement d'une table à partir d'un fichier Excel (de type ".csv") :

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE IF NOT EXISTS `base`
        DEFAULT CHARACTER SET `latin1`
        DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS trav
--------------
 
--------------
CREATE TABLE trav (
  col_num   integer      null default null,
  col_date  datetime     null default null,
  col_char  varchar(255) null default null
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
LOAD DATA LOCAL INFILE 'fichier.txt'
     INTO TABLE `trav`
     CHARACTER SET latin1
     FIELDS TERMINATED            BY ';'
            OPTIONALLY ENCLOSED   BY '\"'
            ESCAPED               BY '\\'
     LINES  TERMINATED            BY '\r\n'
     IGNORE 0 LINES
     (@F1, @F2, @F3)
     set col_num  =             trim(@F1),
         col_date = str_to_date(trim(@F2), '%d/%c/%Y %H:%i:%s'),
         col_char =             trim(@F3)
--------------
 
--------------
select * from trav
--------------
 
+---------+---------------------+--------------------+
| col_num | col_date            | col_char           |
+---------+---------------------+--------------------+
|    NULL | 2014-05-10 15:33:17 | web                |
|     125 | 2014-05-15 23:53:59 | alpha; beta; gamma |
|    -247 | NULL                | zéro               |
+---------+---------------------+--------------------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 0
--------------
 
Appuyez sur une touche pour continuer...

Normalement, je devrais mettre à jour uniquement les colonnes que je modifie, mais je préfère mettre à jour toute la table pour être sûr de ne rien oublier.

Si vous faites une requête de mise à jour par ligne, cela va vous prendre un temps fou.
C'est pourquoi, je vous propose plutôt de passer par le chargement du fichier Excel dans vos tables comme dans l'exemple ci-dessus.

Autrement dit, comment est-ce que j'aurais dû écrire ma requête quand le type est init, tinyint, decimal(20,6), ... ?

Je vous l'ai dit, sans mettre les apostrophes.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
UPDATE  ps_product
   SET  id_product                = 10,
        id_supplier               = 0,
        id_manufacturer           = 3,
...
        ecotax                    = 0.000000,
        quantity                  = 0,
...
        wholesale_price           = 0.000000,
...
 WHERE  id_product                = 10;

D'ailleurs, bstjean, dans son dernier message, l'explique très bien.

Encore une fois, c'est pas moi qui ait décidé de faire comme ça, c'est Prestashop.

Pour les NULL ou les vides, c'est de l'ordre de la modélisation.
Par contre, dans le cas de la date "0000-00-00", c'est vous qui l'avez mis dans votre requête.

Néanmoins, je suis curieux : comment est-ce que j'aurais dû écrire ma requête pour mettre à jour ces 2 colonnes si les valeurs sont redondantes ?

C'est un problème de modélisation ! Je ne vais pas rentrer dans ces détails qui ne sont pas de votre ressort.

@+