Mise a jour 3.67.11 > 3.68.x - probleme date

Soumis par Global-fps le jeu 07/03/2019 - 10:54

Bonjour,
Comme evoqué lors d'un autre sujet, nous avions fait une tentative de mise a jour de la version 3.67.11 vers la version 3.68.1 au mois de Novembre 2018.
La mise a jour ne fonctionnant pas (probleme de mise a jour poste ou gambas), nous avons du revenir a la version 3.67.11.
N'ayant pas cloturé l'exercice precedent, on vient de s'apercevoir que les dates des ecritures ont été modifiées de 1 ou 2 jours (en controllant des factures au hazard de l'exercice) et les AN de l'exercice a cloturer qui ont ete générés lors de la cloture de l'exercice precedent se retrouvent avec une date au 31/03 au lieu du 01/04 ce qui est tres genant (ils sont dans l'exercice precedent cloturé).
Les dates ont du etre modifiée lors de cette mise a jour, car nous avons retrouvé un document imprimé de ces AN avec la date du 01/04.

Est ce qu'il est possible de faire quelque chose
En vous remerciant de votre aide
Cordialement
Dominique

Bonjour,
Non la maj ne modifie pas les dates.
Vous avez plusieurs posts qui tournent autour de la même question mais j'ai un peu de mal à m'y retrouver il faudrait mettre les choses à plat :
- Combien de postes avez vous, 1 serveur ?
- les systèmes d'exploitations + version gambas + version laurux
- De quelle base (sauvegarde) pouvez vous repartir ?

Global-fps

mer 20/03/2019 - 18:46

Bonjour,
nous avons un serveur de base de donnée mysql version 5.5.62-0 fonctionnant sur un serveur 14.04.1
Il y a deux postes de travail qui se connectent sur les bases Laurux

poste 1
V18.04 gambas 3.12.2 Laurux 3.67.11 pour la societe 01 (nous n'arrivons pas a faire passer cette ste sur la version 3.68.4 sur cette societe (ca plante a chaque fois)
V18.04 gambas 3.12.2 Laurux 3.68.4 pour les societes 03 et 06 (ca fonctionne sans probleme)

Poste 2
V18.04 gambas 3.12.2 Laurux 3.68.4 pour les societes 03 et 06 (n'accede pas a la societe 01 - si tentative d'acces a la societe 01 ca plante)

Je suppose que le probleme doit du fait que nous avons fait des tentatives d'upgrade entre la version 3.67.11 et 3.68.x qui n'ont pas fonctionnées.

Concernant les sauvegardes, je n'en fait que sur les clotures d'exercices car j'ai un second serveur (situé dans un autre lieu) configuré en esclave qui assure la replication des bases du serveur maitre. Donc pas de sauvegarde recente pour faire une restauration.

Est ce qu'il existe une possibilité de modification de la base de la ste 01 pour la faire fonctionner sur une version laurux 3.68.4 comme les autres sté ?

Si vous souhaitez plus d'information, je reste a votre disposition

Cordialement
Dominique

Bonjour,
Travailler sur 2 versions de laurux ... C'est pas une super idée.
On va essayer sur le poste 1 :
- Laurux 3.68 on sélectionne la société 01
- Sauvegarde de la base 01, vérifiez bien que Laurux01.sql ne soit pas à 0 octets
- Mise à blanc de la zone numéro de version dans "paramètres généraux"
- Sortir et relancer laurux

Il ne faut que une connections active donc le poste 2 ne doit pas travailler sur le serveur. Après la mise à jour vérifiez vos préférences locales sur toutes les sociétés, le fichier de config étant recopié de la 3.67 à la 3.68.

Global-fps

jeu 21/03/2019 - 11:49

Bonjour,
Je sais bien, mais je n'ais pas d'autres solution pour la ste 01.
sur le poste 1, avec la version 3.68.4, si je selectionne la ste 01, je n'ai plus acces car a l'ouverture j'ai le message suivant:
Unknown field: conf Prefs.ReadGlobal.84
si je clique sur config SQL, les parametres de connections sont corrects, je valide, il relance et je retombe sur le message precedent:
le seul moyen de sortir de la situation, c'est de selectionner une autre base de donnée (exemple Laurux03) dans la config sql.
Si je demarre avec la version 3.67.11, je peux demarrer le programme avec la base Laurux01.
cordialement
Dominique

Global-fps

ven 22/03/2019 - 12:12

Bonjour,
Merci pour votre precieuse aide.

Avec la version 3.67.11 sur le poste 1, j'ai fais une sauvegarde et j'ai essayé de faire une mise a jour mais cela n'a pas fonctionné je retombe sur le meme message et ca plante.

J'ai essayé sur un autre poste configuré en 16.04, gambas 3.12.2 et Laurux 3.67.11 et serveur mysql en local sur lequel j'ai restauré la base 01.
A la fin de la sauvegarde j'ai eu un message que la base etait d'une version differente de la version du logiciel.
Du coup, je pense que le probleme de mise a jour de la base Laurux01 est peut etre plus ancien.
A un moment donné, on avait eu des problemes sur des mises a jour et on avait desactivé mes mises a jours automatiques, et nous avons du en loupé.
Ce que je n'explique pas c'est que pour les autres stes les mises a jours ont été faites sans probleme sauf pour la sté 01.

Comment pourrais-je determiner la version de la base actuelle pour que je refasse toutes les etapes de mises a jour sur le poste que j'ai configuré en local jusqu'a la derniere version. Je procederais ensuite a la sauvegarde et a la restauration sur le serveur

Cordialement
Dominique

Global-fps

ven 22/03/2019 - 19:15

Merci de votre retour
Je procede bien de cette maniere, cependant cela ne fonctionne toujours pas, le passage de la version 3.67.11 a la version 3.68.0, plante systematiquement a l'ouverture avec le message suivant "Unknown field: conf Prefs.ReadGlobal.84" puis cela me redirige vers vers la config de la base, les parametres sont OK, je valide et ca demande de relancer. si je clique sur "OK" retour au point de depart si je clique sur "annuler" ca demarre mais toujours avec le probleme de date qui se modifie.
J'ai tenté la mise a jour entre la version 3.68.1 a la 3.68.4 et je reviens sur le probleme de depart, ca plante systematiquement avec le message suivant "Unknown field: conf Prefs.ReadGlobal.84"
J'ai tenté meme un retour avec une version 3.66.6 en local sur un poste isolé, l'import fonctionne mais le reste impossible, j'ai tenté la mise a jour et le probleme initial reste le meme et le plantage aussi.
la case de la mise a jour de la base est bien activée sur chaque changement de version.
J'avoue ne plus savoir quoi faire et je ne souhaiterais pas ressaisir 14K lignes.
Je peux vous envoyer la base si ca peux aider
Cordialement
Dominique

Global-fps

lun 25/03/2019 - 21:54

Bonsoir,
Merci pour la modif de la base.
j'ai restauré la base Laurux01, d'emblée ca fonctionne et plus de probleme de date lors des saisies.
J'ai corrigé les valeurs qui avait été modifiées dans la table des parametres generaux.

En regardant rapidement, je vois 2 problemes:

- Le premier concerne les AN qui ont été saisis au 01.04.2017, dans la base, ils apparaissent bien a la date du 01.04.2017 sous l'ecriture 10646, et quand je fais une impression du GL general du 01.04.2017 au 01.04.2017, ces ecritures ne ressortent pas.
- 2 - Lorsqu'on veut sortir un SIG de l'exercice 2017/2018, les ventes n'apparaissent pas (aucun chiffre n'apparait comme si elles n'existaient pas).
le meme probleme est present sur les exercices anterieurs sauf pour celui de 2018/2019

Avant de recommencer a travailler dessus, nous allons faire des verifications.
et on vous tiens informé de nos decouvertes.

Cordialement.
Dominique

Global-fps

mar 26/03/2019 - 14:01

Bonjour,

Lors de l'impression de la balance générale pour l'exercice n-1, les classes 1,2,3 et 7, 8 ne sont pas renseignées...Les soldes sont à 0.
Merci pour votre travail sur notre base.

Bien cordialement,
Véronique

Global-fps

jeu 28/03/2019 - 02:20

Bonsoir,
pour essayer de comprendre le probleme, j'ai regardé la structure des table Mvt, Mvt1, Mvt2, Mvt3 entre la base Laurux 01 et Laurux 03, et je m'apercois que c'est un peu le bazard dans les champs.
Dans Laurux01 (societe dans laquelle j'ai des problemes)
Mvt 31 col
Mvt1 27 col
Mvt2 28 col
Mvt3 28 col
Dans Laurux03 (societe fonctionnelle)
Mvt 30 col
Mvt1 30 col
Mvt2 28 col
Mvt3 28 col
Je ne sais pas comment on en est arrivé la, je ne sais pas comment je peux corriger cela, mais je pense qu'une partie des problemes viennent de la.

Je viens de creer un nouvelle structure Laurux11
Dans Laurux11 (societe nouvelle)
Mvt 28 col
Mvt1 28 col
Mvt2 28 col
Mvt3 28 col
Je ne comprends pourquoi en fonction des societes les champs des bases sont differents, et parfois ordonnés differement.

En vous remerciant de votre retour
Cordialement
Dominique

Bonjour,
Vérifiez vos dates d'exercice, la dernière doit être du 31/03/2018 puis 31/03/2017 ect...
Pour moi ça marche.
Le nombre de colonne dépend des différentes maj qui ont étés faites sur la base.