Discussion :

[Stigger]

Bonjour,

Voilà, nous avons eus un soucis d'enregistrement dernièrement, et celà a provoqué quelques problèmes.
Je souhaiterai mettre à jour une Table d'une ancienne sauvegarde de ma base de données, avec les enregistrements effectués sur la table du même nom, et même structure, enregistrés sur la base actuelle. J'ai essayé le code SQL suivant :

Code :

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

1
2
3
INSERT INTO [Orientations Hotel Ancienne version]
SELECT 
FROM [Orientations Hotel] INNER JOIN [Orientations Hotel Ancienne version] ON [Orientations Hotel].ID_orientation = [Orientations Hotel Ancienne version].ID_orientation;

créé avec le bouton de requête. Or, Access (version 2013), après m'avoir généré tout seul ce code, me signale qu'il y a une erreur dans celui ci.

Je n'arrive vraiment pas à comprendre la logique d'access, et je me perds en essayant de comprendre. Je ne sais même pas si cette solution règlera mon problème, mais j'aimerai réussir pour vérifier ><

Merci,

[james68]

je dirais qu'il faut le faire en deux phases:
d'abord
l'ajout ( insert into) pour ajouter les enr manquants.
après
la MAJ ( update .. ) pour mettre a jour tous les champs
Attention : ne pas utiliser les ID (numéroauto) pour faire la jonction car il risque d’être différent d'une table a l'autre.
++

[nico84]

Bonjour,

Si Table1 et Table2 sont dans la même session access et ont les mêmes colonnes, cette syntaxe est ok :

Code :

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

insert into table2 select * from table1

Si table2 est vide alors la requete suivante ne renvoit rien :

Code :

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

select * from table1 inner join table2 on ...

Si les 2 tables sont dans 2 bases qui ne sont pas liées dans une même session alors cela ne marche pas non plus...

[Stigger]

je dirais qu'il faut le faire en deux phases:
d'abord
l'ajout ( insert into) pour ajouter les enr manquants.
après
la MAJ ( update .. ) pour mettre a jour tous les champs
Attention : ne pas utiliser les ID (numéroauto) pour faire la jonction car il risque d’être différent d'une table a l'autre.
++

En fait les numéro auto des enregistrements sont les mêmes, pour ceux existants, mais ceux ayant été créés eux n'existent pas dans l'ancienne table.

Il me faudrait donc un code qui mets à jour les données de l'ancienne table, avec les données de la nouvelle, ET qui créé dans l'ancienne table les enregistrements de la nouvelle qui n'existent pas.
Le plus simple serait de copier la table et la recoller dedans, malheureusement, le problème que nous avons ne se résout pas en faisant un copié collé. Un des enregistrements de la version actuelle de la table est corrompu, mais ayant 70509 enregistrements, je ne peux me permettre de tous les passer en revue. La personne ayant créé la base de données m'a dit qu'en faisant une requête d'ajout / Mise à jour pour enregistrer à partir de l'ID_Orientation, et mettre à jour les nouveaux enregistrements sur une ancienne table.

donc je suppose qu'il me faut faire cette requête comme je l'ai expliqué plus haut.

Avec le update ça donnerait :

Code :

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

1
2
3
4
5
INSERT INTO [Orientations Hotel Ancienne version]
SELECT 
FROM [Orientations Hotel] INNER JOIN [Orientations Hotel Ancienne version] ON [Orientations Hotel].ID_orientation
UPDATE [Orientations Hotel Ancienne version]
SET

?

Je suis désolée, je suis vraiment pas bonne en programmation, je suis en cours de formation, mais j'ai tellement de problèmes à gérer avec le parc informatique que je n'avance plus.

merci, Nico84, je vais essayer

[Stigger]

Alors j'ai essayé la solution de Nico84, c'est un demi échec.
Les enregistrements de mon ancienne table passent bien de 70509 enregistrements à 70594, mais certains de ces enregistrements ont été altérés, et un message d'erreur s'est affiché :


Point de craintes, je travaille sur des copies en local bien sûr, pas de risque pour les données de l'entreprise.
Mais à quoi est dûe cette erreur, et comment faire pour l'éviter ?

le code :

Code :

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

1
2
3
INSERT INTO [Orientations Hotel Ancienne version]
SELECT *
FROM [Orientations Hotel ];

[nico84]

Les 59752 sont les enregistrements déjà existants qui ne peuvent pas se recréer à nouveau

Ma syntaxe était adaptée si table2 était vide. Si elle a déjà des enregistrements, la syntaxe suivante ajoute uniquement les nouveaux :

Code :

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

insert into table2 select table1.* from table1 left join table2 on table1.cle=table2.cle where table2.cle is null

Pour l'update c'est plus complexe car on ne sait pas à priori quels champs sont modifiés... S'il y en a bcp le plus simple est de vider d'abord table2 et de tout réinsérer !

[Stigger]

Les 59752 sont les enregistrements déjà existants qui ne peuvent pas se recréer à nouveau

Ma syntaxe était adaptée si table2 était vide. Si elle a déjà des enregistrements, la syntaxe suivante ajoute uniquement les nouveaux :

Code :

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

insert into table2 select table1.* from table1 left join table2 on table1.cle=table2.cle where table2.cle is null

Pour l'update c'est plus complexe car on ne sait pas à priori quels champs sont modifiés... S'il y en a bcp le plus simple est de vider d'abord table2 et de tout réinsérer !

Et bien, elles sont toutes deux identiques, sauf que l'une est à une date antérieure, donc sans les ajouts d'aujourd'hui.
Mon problème est que sur un des PC, lorsqu'une de nos coordinatrice ajoute un enregistrement, ça fait planter toute la base chez tout le monde,
et depuis, les formulaires de la facturation hôtel ne fonctionnent plus.

En mettant à jour l'ancienne table, avec les données de l'actuelle, apparement cela règlerai le problème. Alors que si je vide la table, pour ajouter les enregistrement de l'actuelle à la place, les calculs du formulaire facturation ne se font toujours pas.


Pas de message d'erreur cette fois ci, mais il y a toujours altération des données, puisque mon total de nuits passe de 635364 à 635487.
Et l'erreur est également au même enregistrement. Est ce que cela veut dire que les données qui sont modifiées, sont celles qui ont été corrompues lors du plantage qui se faisait à chaque enregistrement de cette coordinatrice ?

Vraiment désolé pour le casse tête, mais la base est conséquente, avec plus d'une centaines de formulaires en interface, une trentaine de personnes travaillant dessus, et comble de l'horreur, sur les pc les versions d'access diffèrent (2010, 2013, 2016) et je dois gérer tous les problèmes mais j'ai trop à faire, je peux difficilement expliquer avec précision mon problème, et je dois respecter la protection des données ><

encore merci de m'aider !!

[james68]

C'est sur...
Si j'avais les 2 tables ca serait fait en 10 min.... lol...
Cela m'est deja arrivé,
je n'(ai pas eu le choix de trouvé l'enr corrompu de le supprimer et et de recréer en fonction de la structure relationnelle.
dans un premier temps il faut que tu retrouves toutes tes données dans la version OLD ( même nombre et même clé )
ensuite il faudra rapatrier les MAJ de la version courante vers la OLD.

[Stigger]

C'est sur...
Si j'avais les 2 tables ca serait fait en 10 min.... lol...
Cela m'est deja arrivé,
je n'(ai pas eu le choix de trouvé l'enr corrompu de le supprimer et et de recréer en fonction de la structure relationnelle.
dans un premier temps il faut que tu retrouves toutes tes données dans la version OLD ( même nombre et même clé )
ensuite il faudra rapatrier les MAJ de la version courante vers la OLD.

Très bien merci !! Je vais demander à la coordinatrice de me retrouver les orientations sur papier pour savoir laquelle est à prendre en compte, puis je ferais la chasse aux enregistrements corrompus ! en espérant qu'il n'y en ai pas tant, et restreint jusqu'au 14 Septembre, date à laquelle ont eus lieux les problèmes de saisie. Parce que si je dois chercher dans les 70594 enregistrements...

Encore merci, je reviendrais poster le résultat une fois fait ^^
Bonne journée,
Stig

[james68]

as tu des champ memo dans ta table principale ?
Pour ma part c'est là que ca avait merdouillé...

[Stigger]

as tu des champ memo dans ta table principale ?
Pour ma part c'est là que ca avait merdouillé...

Si en effet, le chant "Note" est de type mémo. Ce que je ne comprends pas, c'est que jusqu'au 14 Septembre, il n'y avait jamais eu de problème, alors que la base a été créée en 2013 !! Sans raison, cette personne ne peut plus effectuer de saisie sur son ordinateur, mais d'autres peuvent, sur leur PC, faire ces mêmes saisies...

En retrouvant les orientations papiers, il s'avère qu'un enregistrement avait été fait pour un séjour de 7 nuits, du 18 au 25 Septembre, qui a été annulé en cours de route pour le passer à 3 nuits, du 18 au 21 Septembre. C'est pour cela que l'enregistrement n'est pas modifié lors de la mise à jour, alors qu'il faudrait que cette donnée soit écrasée ? N'est ce pas dangereux d'écraser la donnée dans le code ?

Le code fonctionne donc bien pour les nouveaux enregistrements effectués dans la table, mais ne met pas à jour les données existantes, il les laisse comme elles étaient.

[james68]

franchement je n'ai pas l' ossature de ton code ni de ta structure.
il est un peu difficile de répondre a ce type de question.
Perso j'ai eu des problème de stabilité lors d'une coupure de courant sur le serveur ou était stocké la BDD.
Un client devait etre en écriture sur cet enr lors de la coupure brutale.
La base de données a redémarrer correctement cependant que tu voulais modifié l'enr en question...
Acces démarrait les messages d'erreur a n'en plus finir.
J'ai du supprimer l'enr en question et le recréer dans la BDD principale et refaire les liens dans les tables sous-jacentes.
Je l'ai trouvé facilement en jouant sur les tri croissant et décroissant directement dans la BDD.
Je ne me souviens plus trop ce qu'il m'affichait dans le champs mais tu ne pouvais pas le rater( ### supprimé/// un truc dans le genre )
++

[nico84]

Pas de message d'erreur cette fois ci, mais il y a toujours altération des données, puisque mon total de nuits passe de 635364 à 635487.

Ca augmente donc ça correspond avec les lignes ajoutées

Avec 30 utilisateurs on est aux limites d'une base de données d'access. Est-ce découpé frontale + dorsale ? Si oui : taille de la dorsale ? Est-elle compactée tous les jours ?

[Stigger]

Ca augmente donc ça correspond avec les lignes ajoutées

Avec 30 utilisateurs on est aux limites d'une base de données d'access. Est-ce découpé frontale + dorsale ? Si oui : taille de la dorsale ? Est-elle compactée tous les jours ?

Alors, cette base est une horreur. Elle a été faite par qqun n'ayant pas forcément de connaissances en base de données, et même si son travail pour son niveau est remarquable, on note énormément d'erreur. Je dis 30 utilisateurs, mais c'est en moyenne d'utilisation, nous sommes 43 utilisateurs dessus, mais pas toujours connectés, et pas toujours présents là journée. Certains ont des déplacements à faire dans les hôtels, d'autres des recherches et des saisies, etc. La période hivernale en approche, nous en rajoutons déjà 4, et peut-être plus à venir...
Le créateur de cette base a scindée sa base en deux, je pense que c'est ce que tu entends par frontale + dorsale, d'un côté les tables, de l'autre les formulaires, requêtes etc.
Là, hébergée en réseau, ce qui la rend souvent instable, il a créé pour chaque utilisateur une interface, soit 43 dossiers au nom de chaque utilisateur, avec son fichier interface, chacun ayant une version d'access qui ne correspond pas forcément à son voisin.
Il arrive souvent que l'interface d'un utilisateur plante, et que je sois obligée de remplacer le fichier par un qui fonctionne. Le fait que les versions ne soient pas les mêmes, et que ce soit sur un réseau dont on nous alloue un espace, ça rend la base vraiment instable et compliquée à gérer. De plus, l'interface comporte plus de 95 Formulaires, et au moins une quarantaine ou cinquantaine de requêtes en tous genre. Et on ne cesse de demander des améliorations, des formulaires supplémentaires, etc.

Au moins, je ne m'ennuie pas !

Pour le compactage, la base est compactée tous les jours oui, et je fais systématiquement une copie de la base source en local par mesure de sécurité, mon côté parano :p

Bonne fin de journée, je vous dirais demain si j'ai réussi à régler mon problème, pour le moment c'est la chasse aux enregistrements corrompus qui changent.
(ça augmente trop, lorsqu'on a un séjour du 18 au 21, on a 3 jours qui se comptabilisent, mais si on modifie jusqu'au 25, on en a 5. Le cas ici que j'ai trouvé, on a enregistré une personne pour 5 nuits, puis on a modifié son enregistrement en 3 jours. C'est ce qui a posé problème puisque lorsque je fais la requête de mise à jour, il garde en compte 5 jours, là où il devrait avoir mis 3 jours.)

[Stigger]

Bonjour,

Juste pour préciser que le problème est résolu, J'ai repris tout à zéro et fait une mise à jour d'une ancienne table, en ajoutant les nouvelles données saisies depuis cette date à la main. Tout fonctionne, mes calculs se font à nouveau, les listes déroulantes fonctionnent...

Merci pour votre aide !