Crash - commande et réception commande fournisseur v3.68.1 (6157158 branche master)

[brunoc68]

Les commandes et réceptions automatiques ne fonctionnent pas correctement à cause des lock.

Explications réception automatique :

• lors d'une réception automatique, un message "UnLock sur le document Reception...Erreur lock inexistant". Mais il n'y a pas d'incidence sur l'enregistrement
• lorsque l'on édite le document en question la première fois, ça fonctionne
• lorsque l'on veut rééditer le document en question, le logiciel plante : "Query failed: Duplicate entry... DB_Connection.Exec.277"

C'est le même problème au niveau de la commande fournisseur : lock inexistant, et plantage à la réédition. Dans le cas de la commande on a même une perte définitive du document lors du plantage !

Le problème "Erreur lock inexistant" ne semble pas avoir d'incidence sur le fonctionnement du logiciel.

Pour le problème de plantage, il est lié à un enregistrement qui ne s'en va plus dans Fiches_Docactif ; j'ai résolu provisoirement le soucis en lançant le script suivant toutes les minutes :

root:root 755 /etc/cron.d/unlockLaurux :

• • • • • root /bin/echo "delete from Fiches_Docactif where doc_type='Reception' or doc_type='CommandeF';" | /usr/bin/mysql -u root -pmotdepasse Laurux01

[damscot]

je ne suis arrivé a reproduire un pb equivalent lorsque l'on edite le numero automatique de commande fourni par Laurux... j'ai l'impression que ton client change régulièrement les numéro attribué automatiquement (numero de BL, numero de commande)...
je pense que c'est pour cela qu'il y a des pb a recurrence.
Damien.

[brunoc68]

Moi je reproduis le problème à tous les coups, mais tu m'as mis sur une piste.

Le premier problème "lock inexistant" ne se produit que lorsque l'on indique un numéro de BL. Ca n'arrive pas quand j'utilise F9 pour attribuer un numéro de BL automatiquement. Or le numéro de BL est en général à la réception celui du fournisseur, il n'y a aucune raison que Laurux le connaisse. Sauf si sur chaque BL fournisseur on indique notre propre numéro.

Pour la deuxième erreur : n'est-ce pas un problème de duplicate entry ? En effet, si on utilise les numéros de BL des fournisseurs, il n'y a aucune raison de ne pas avoir plusieurs fois le même numéro...

[damscot]

oui c'est probablement cela... le lock s'appuie sur le numero de document attribué automatiquement avec F9... je n'avais pas pensé que l'on pouvait utiliser un autre numéro...
le pb d'utiliser le meme numero est que la base de donnée l'utilise ce champ comme clef primaire il est donc possible que l'utilisateur attribue un numero de BL qui va conflicter avec l'autoincrement fait par F9.
Quel est l'option activé sur le poste dans Gestion(1) -> Parametres Stock -> Saisie Manuel des numeros de BL fournisseur

j'ai regardé comment fonctionne cette option, elle permet effectivement de choisir soit meme son numero de BR (pas supporté avec le lock actuel), ici il s'agit donc bien d'un bug.

par contre cette option n'a pas d'effet en reception automatique... du coup il devrait etre interdit de modifier ce champ quelque soit l'option mise.

en reception manuelle si l'option n'est pas coché il devrait etre interdit de changer ce champ...

je sais pas trop quoi faire ici, @Laurux tu as une idée.

[damscot]

@brunoc68 je viens de faire un fix global pour se ticket (option numbr manuel/automatique fixé)
peux-tu vérifier que tu n'as plus de pb.

realigne ta branche sur master et compile Laurux.

[Laurux]

La table des entetes (Fiches_Entrecpt) a une clé primaire = four & numrecpt donc il ne peut pas y avoir de doublon.

[damscot]

le pb de lock est corrigé pour la 3.68.2, le lock utilisait que numrecpt et pas four d'ou le pb... pour la 3.69, il faudra agrandir le champ numdoc dans DocActif 2018-02-28 12:02 GMT+01:00 Laurux <notifications@github.com>:

…

La table des entetes (Fiches_Entrecpt) a une clé primaire = four & numrecpt donc il ne peut pas y avoir de doublon. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANmrXbQxJ4bH_GTclqsiOON8HndZX27Bks5tZTJOgaJpZM4SQlY8> .