Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 17 sur 17
  1. #1
    Invité régulier
    Profil pro Mur Mikael
    Inscrit en
    avril 2010
    Messages
    133
    Détails du profil
    Informations personnelles :
    Nom : Mur Mikael

    Informations forums :
    Inscription : avril 2010
    Messages : 133
    Points : 9
    Points
    9

    Par défaut Correction automatique des tables endommagées

    Bonjour à tous,

    j'utilise une application delphi dont la base de données est sous paradox.

    L'application est en réseau, le problème est que les tables sont souvent endommagés (générateur autoincrément corrompu, violation de clé).

    Ce probléme provient des micro-coupures wifi (un grand merci à FDR2006 et SQLpro).

    Vu l'impossiblité de faire un câblage, je suis à la recherche d'un moyen pour la correction automatique de ces tables.

    J'ai trouvé la solution Pdxrbld , mais elle me parrait que c'est une solution manuelle.

    Si quelqu'un possède une idée elle sera la bien venue.

    **Merci**

  2. #2
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    445
    Détails du profil
    Informations personnelles :
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2009
    Messages : 445
    Points : 710
    Points
    710

    Par défaut

    Bonjour,

    Quelques questions avant d'envisager une réponse.

    Tes tables ou certaines possèdent-elles un index primaire auto-incrémenté ?
    Certains index primaires auto-incrémentés sont-ils placés comme clés étrangères dans d'autres tables ? (Table maître -> Table détail).

    Si tu réponds oui à ces deux questions, il me semble impossible de réparer en automatique des tables, car les index primaires sont actualisés à partir de 1, d'où la suppression de la liaison avec les tables de détail.

    Autrement, il existe l'outil TUtil32 pour réparer en automatique les tables paradox. Tu dois le trouver sur internet, sinon je pourrai te l'adresser.

    A mon avis, compte tenu de ton problème, que j'avais aperçu sur un autre forum avec les réponses, il te faudra envisager une autre approche que la réparation automatique. Toutes ces méthodes plus ou moins bien ficeler, d'ailleurs plutôt moins que plus, ne peuvent conduire que vers une perte de données.

    J'ai une application qui tourne depuis 10 ans sur un réseau câblé, nous n'avons eu aucun incident. Mais depuis, je suis passé au client / serveur pour les nouveaux développement.

    Bon courage et surtout beaucoup de chance pour résoudre ton problème

    A plus

  3. #3
    Membre du Club
    Homme Profil pro
    Inscrit en
    mars 2006
    Messages
    84
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Argentine

    Informations forums :
    Inscription : mars 2006
    Messages : 84
    Points : 66
    Points
    66

    Par défaut

    Bonjour,

    Pour plus d'info:

    Les deux Q. qui t'a posé Seabs sont très justes et font déconseiller l'approche de la réparation automatique.

    L'Utilitaire TUtility fait partie de Paradox. Toutes les versions depuis Paradox 7 te conviennent, puisque le format des tables est "gelé" depuis Paradox 7. C.a.d. que P7, P8 > P11 utilisent le format Paradox 7.

    Mais TUtility n'est pas automatique, c'est une option de menu qui te permet dans la plupart des cas ( mais pas forcément toujours ) de faire soit un diagnostic soit un "rebuild" de ta table. Mais, à ma connaissance, toujours avec un opérateur, et non avec ligne de commande.

    Une dernière possibilité de "reconstruction automatique" ce serait que tu programmes un "datapump" qui soit capable de lire les données des tables endomagées et puisse écrire sur un jeux vide des tables saines. Mais alors tu dois te faire responsable du contrôle de toutes les exceptions. Point de vue conceptuel c'est simple, mais tu ne verras toutes les exceptions que sur ton chemin... et c'est long.

    Bonne journée

  4. #4
    Invité régulier
    Profil pro Mur Mikael
    Inscrit en
    avril 2010
    Messages
    133
    Détails du profil
    Informations personnelles :
    Nom : Mur Mikael

    Informations forums :
    Inscription : avril 2010
    Messages : 133
    Points : 9
    Points
    9

    Par défaut

    Merci FDR2006 pour votre réponse, mais en quoi ca peut m'aider? c'est trop vague.

  5. #5
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    445
    Détails du profil
    Informations personnelles :
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2009
    Messages : 445
    Points : 710
    Points
    710

    Par défaut

    Bonjour,

    Grâce à FDR2006, j'ai actualisé quelques points oubliés.

    Pour t'aider, il faudrait en connaître un peu plus sur tes difficultés.

    L'application est en réseau, le problème est que les tables sont souvent endommagés (générateur autoincrément corrompu, violation de clé).
    Le terme souvent veut dire plusieurs fois par heure, par jour, par semaine ou par mois, car suivant la fréquence la réponse sera différente.
    Il serait bon d'indiquer le nombre de personnes qui utilisent la base en même temps. Le risque de conflit en écriture par plusieurs intervenants simultanés. Ne pas oublier tout autre point qui peut accroître la difficulté

    De toutes façons, pour une réparation automatique, il faut modifier le schéma des tables afin de ne pas être bloqué par l'autoincrémentation et les clés étrangères. J'ai quelques idées sur ce point, mais il convient de faire quelques tests pour valider mes hypothèses.

    Si les modifications deviennent trop importante, mieux vaut passer à Interbase ou Firebird.

    Ne pas oublier le problème du matériel pour assurer un amélioration de la transmission WIFI. Je n'ai aucune connaissance dans ce type de transmission car je pense qu'elle ne procure que des ennuis (Erreurs, confidentialité, Hadopi, etc.). Par contre, il est peut être possible d'envisager un réseau CPL qui ne nécessite aucun câblage et fonctionne parfaitement si l'installation électrique est correcte. Le coût est modeste 60 € maximum pas poste pour un produit haut gamme. Personnellement, j'utilise ce système depuis deux ans avec une satisfaction à 100%.

    A bientôt pour la suite

  6. #6
    Invité régulier
    Profil pro Mur Mikael
    Inscrit en
    avril 2010
    Messages
    133
    Détails du profil
    Informations personnelles :
    Nom : Mur Mikael

    Informations forums :
    Inscription : avril 2010
    Messages : 133
    Points : 9
    Points
    9

    Par défaut

    Bonjour seabs et merci bien pour votre coup de main,

    Voici quelques points pour vous clarifier la situation :

    1- Pour la fréquence des erreurs, on peut les estimés par 5 ou 6 erreurs par jour.


    2- Pour l'architecture du RSO, on a un superviseur qui gère l'accès des postes clients au ServeurBD, un serveurBD qui localise toutes les données des postes clients, et pour le moment on a 13 postes clients. Les données des postes client sont enregistrés en local, puis une mise à jour automatique s'effectue sur le serveurBD pour importer les données des postes clients.

    3- Concernant le réseau CPL, il s'est avéré qu'il est impossible de le faire au niveau de l'usine car le courant n'est pas stable.

    4- Pour le signal du réseau wifi, on va essayer de l'améliorer car il n'est pas optimal.

  7. #7
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    445
    Détails du profil
    Informations personnelles :
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2009
    Messages : 445
    Points : 710
    Points
    710

    Par défaut

    Bonjour,

    Le nombre d'incidents est important, d'où la nécessité de remédier à cette situation. Actuellement, tu remets le serveur à niveau comment ?

    Si j'ai bien compris, le mouvement des données se fait des postes clients vers le serveurDB. Par contre, le serveur envoie t-il des données vers les postes clients ? Les données locales sont-elles stockées dans une base Paradox ?

    Si ma réflexion est exacte, le serveur va lire les tables des postes clients, puis fait l'inclusion dans le serveur. Les incidents se produisent lors de l'importation, car les tables importées se retrouvent avec des index cassés ou des pertes de données.

    Lors de l'importation, les postes clients continuent de fonctionner et d'enregistrer des données. Ce point doit être examiné car il est peut être la cause des incidents (simple supposition). Combien y a t-il de tables sur un poste clients ?

    Comme il s'agit d'une usine, les données sont entrées manuellement ou en automatique par connexion à des machines dans les postes clients ?

    Je pense que je n'ai pas encore tout compris, mais cela venir. Tu m'indiques la partie de ma réflexion qui est inexacte. Si ma démarche est bonne, nous verrons comment traiter la difficulté pour éviter ou en tout cas réduire le nombre d'incidents journaliers

    Valide ou modifie mon approche. En fonction de tes réponses, il me sera possible te donner quelques pistes pour traiter tes difficultés. Mais, à mon avis, il y aura certainement un peu de programmation.

    A plus et bon courage

  8. #8
    Invité régulier
    Profil pro Mur Mikael
    Inscrit en
    avril 2010
    Messages
    133
    Détails du profil
    Informations personnelles :
    Nom : Mur Mikael

    Informations forums :
    Inscription : avril 2010
    Messages : 133
    Points : 9
    Points
    9

    Par défaut

    Bonjour seabs,

    Pour info c'est pas moi qui a devellopé l'application, mais j'en ai le code source.

    Votre réflexion est toute a fait correcte;

    J'ai pas bien compris qu'est ce que vous voulez dire par mettre à niveau le serveur (si c'est la mise à jour elle se fait automatiquement, normalement par des selectes sur les postes clients)

    Oui, le serveurBD envoie des données vers les postes clients (l'opération se fait par un click sur le bouton mise à jour du poste client ).

    Sur le poste client on a deux dossiers de tables paradox; un dossier "DataImage" contient 4 tables qui stockent les données qui proviennent du serveurBD lors de la mise à jour du poste client, et un dossier "DataModule" qui contient 4 tables, qui enregistrent les données du poste lui même, qui sont saisie manuellement par un opérateur.

    Les incidents se produisent uniquement sur les postes clients, parfois lors de la mise à jour lorsque les tables de "DataImage" sont endommagés, mais le plus souvent lors d'un insert sur un poste client (saisi des données) lorsque les tables de "DataModule" sont endommagés.

    Pour information, le serveur importe les données des postes clients par des fichiers textes, qui sont ensuite traités et enregistrés dans les tables paradox
    Je pense que lorsque les tables des postes clients sont endommagés, le transfert vers le serveurBD ne s'effectue pas, car j'ai pas des messages d'erreur sur le serveur.

    Merci infiniment.

  9. #9
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    445
    Détails du profil
    Informations personnelles :
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2009
    Messages : 445
    Points : 710
    Points
    710

    Par défaut

    Bonjour,

    J'étais absent 2 jours, d'où mon retard dans la réponse.

    J'ai pas bien compris qu'est ce que vous voulez dire par mettre à niveau le serveur (si c'est la mise à jour elle se fait automatiquement, normalement par des selectes sur les postes clients)
    Oui, il s'agit bien de cela.
    D'après vos indications, il semble que les erreurs se produisent uniquement sur le postes clients.
    Il faudrait faire des essais pour savoir, si les erreurs débutent après la mise à jour par le serveur du poste client. L'écriture se fait directement du serveur dans les tables du poste client, si cela est le cas, il serait peut être préférable de créer un fichier en mode texte sur le serveur pour préparer la mise à jour, puis d'expédier ce fichier vers le poste client qui lui fera la mise à jour.

    L'idée générale est d'éviter que le trafic Wifi transfert des tables de paradox. Les informations transférées sont préparées dans un fichier texte, cvs ou autres. A leur arrivée sur le poste, elle sont vérifiées par un programme à mettre en oeuvre, puis le poste lit les données et les inclut dans les tables locales. Cette approche doit éviter le cassage des index.

    Maintenant, tout cela n'est pas très simple à mettre en place et nécessite un peu de la programmation.

    Je pense que le premier point à détecter, c'est quand les index cassent. Après, il sera possible de mieux prévoir le remède.

    Par ailleurs, êtes-vous certain que l'erreur sur les index ne provient pas d'une erreur de programmation de l'application.

    J'ai peut être écrit des choses farfelues, à vous de me corriger.

    Ne pas oublier, qu'avec Paradox, un code sur un poste local
    Code :
    SELECT * FROM NomTableServeur WHERE Filtre
    Conduit aux opérations suivantes :
    • Transfert de la totalité de la table du serveur vers le poste local
    • Lecture des éléments à traiter et insertion dans les tables locales

    C'est au moment du transfert par Wifi de la totalité de la table que des erreurs peuvent se produire. L'absence d'information conduit vers incident qui chez Paradox a pour conséquence de casser les index

    A plus et bon courage.

  10. #10
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    445
    Détails du profil
    Informations personnelles :
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2009
    Messages : 445
    Points : 710
    Points
    710

    Par défaut

    Bonjour,

    En complément de ma réponse ci-dessus, il faudrait vérifier si lors de l'enregistrement dans les tables locales par l'opérateur, ces dernières ne sont pas en cours de mise à jour par le serveur.

    J'ai eu des soucis avec des tables en mode Edit. Il faut mieux, pour la mise à jour ne pas utiliser les composants TDBEdit, mais prendre TEdit et suivre le schéma suivant :
    Code :
    1
    2
    3
    Passer la TABLE en mode Edit
    Inclure dans chaque colonne les informations
    Faire un Post
    L'opération se fait en quelques millisecondes, d'où probabilité faible de faire télescoper deux opérations. Risque d'erreurs très réduit.

    Depuis, je fais mes écritures en SQL dans mes tables Paradox ce qui m'a supprimer ce type de difficultés.

    Voila une série de réflexion à conduire pour éviter des problèmes actuels.

    Bon courage

  11. #11
    Invité régulier
    Profil pro Mur Mikael
    Inscrit en
    avril 2010
    Messages
    133
    Détails du profil
    Informations personnelles :
    Nom : Mur Mikael

    Informations forums :
    Inscription : avril 2010
    Messages : 133
    Points : 9
    Points
    9

    Par défaut RE

    Bonjour seabs,
    Merci bien pour tes réponses. Ca me donne plusieurs réflexions.

    J'ai découvert quelque chose qui peut aider :

    La mise à jour au niveau du serveur ne se fait pas par des selects sur les postes clients.

    Lorsque une transaction se fait sur le poste client par l'opérateur (click sur un bouton ), deux messages de validation s'affichent, le premier est pour l'insertion dans la table paradox du poste local (à ce niveau normalement on a pas de problèmes), le deuxième est pour l'envoi des données au serveur, dans le cas normale, lorsqu'on valide, un fichier texte se crée dans un dossier sur le serveur, qui contient les données de la transaction.

    j'aime bien comprendre la procédure de création de ce fichier: es-ce qu'il est crée sur le poste local puis envoyé au serveur, ou bien crée vide sur le serveur puis les données sont inscrites( ce qui je pense le cas).

    Es-ce que le problème peut être a ce niveau.??

    Merci et A plus

  12. #12
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    445
    Détails du profil
    Informations personnelles :
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2009
    Messages : 445
    Points : 710
    Points
    710

    Par défaut

    Bonjour,

    j'aime bien comprendre la procédure de création de ce fichier: es-ce qu'il est crée sur le poste local puis envoyé au serveur, ou bien crée vide sur le serveur puis les données sont inscrites( ce qui je pense le cas).
    Effectivement, la difficulté peut se situer ici.

    Pour améliorer la sécurité, il faudrait créer le fichier sur le poste local, calculer l'empreinte du fichier en MD5. L'expédier sur le serveur, puis vérifier si l'empreinte est identique. Si oui, faire le transfert vers la base de données du serveur. Si l'empreinte est fausse recharger le fichier afin que l'empreinte soit exacte. Pour réduire ton risque, s'il est lié au transfert des données, il faudrait procéder suivant le même principe pour l'envoi du serveur vers les postes locaux.

    En principe, les index ne cassent pas pour les opérations faites en local, sauf s'il existe un incident lié à l'environnement ou au programme. J'ai eu une fois ce souci.

    Maintenant, l'envoi des données du serveur vers les postes clients ne comporte-t-il pas des risques d'erreurs ?

    Si tu le désires, tu peux m'adresser les sources et un jeu de tables vides ou pas, ainsi je pourrai faire des essais. Je travaille en Delphi 7 et dispose d'un réseau en CPL.

    Tu n'as pas réussi à déterminer l'instant où les index cassent car cela réduirait le champ des recherches.

    A plus

  13. #13
    Invité régulier
    Profil pro Mur Mikael
    Inscrit en
    avril 2010
    Messages
    133
    Détails du profil
    Informations personnelles :
    Nom : Mur Mikael

    Informations forums :
    Inscription : avril 2010
    Messages : 133
    Points : 9
    Points
    9

    Par défaut re

    Bonjour seabs,

    Ce qui m'étonne est que les index des tables locales qui sont souvent endommagés, je pense que c'est une conséquence du problème principal car, lorsque l'application bloque (problème principal du transfert WIFI), on ne peut pas la fermer que par un 'ctrl+alt+supp', ce qui provoque le cassage des index.

    Pour les sources l'application est trop grande, en plus je suis débutant en delphi, donc j'arrive pas à localiser la source exacte.

    Je suis actuellement en train de m'informer sur le langage pascal afin de comprendre la source et localiser la source du problème.

    Comme j'ai dit plus haut, je n'arrive pas, pour l'instant, à déterminer l'instant exact du cassage des index.

    Je vous contacte dès qu'il y a des nouvelles.

    A plus.

  14. #14
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    445
    Détails du profil
    Informations personnelles :
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2009
    Messages : 445
    Points : 710
    Points
    710

    Par défaut

    Bonjour,

    Il est certain que si tu arrêtes une application par "ctrl+del+supp", les dégâts sont immédiats et les index sont pratiquement cassés à chaque fois.

    Pour vérifier si le problème vient du Wifi ou d'ailleurs (En informatique, l'erreur n'est pas toujours où nous cherchons), il serait possible de mettre un poste client à côté de ton serveur et de créer un mini réseau avec câble croisé ou autre technique. Là, tu pourrais faire des essais et s'il n'y a aucune cassure d'index, nous saurions que le problème est lié au Wifi.

    Le problème peut se situer par le plantage de ton application sur le poste local, d'autant que tu sors par "ctrl+del+supp".

    Il faut commencer par éliminer tout ce qui ne peut pas conduire vers une cassure des index. Ensuite, il sera plus simple de faire des investigations.

    Si tu peux compiler l'application d'un poste client, il est peut possible d'inclure des témoins afin de voir quand la cassure se produit.

    J'essaie de trouver des idées pour t'aider, mais peut être que je suis hors sujet.

    Bon courage

  15. #15
    Membre du Club
    Homme Profil pro
    Inscrit en
    mars 2006
    Messages
    84
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Argentine

    Informations forums :
    Inscription : mars 2006
    Messages : 84
    Points : 66
    Points
    66

    Par défaut

    Bonjour Sniperpro, Seabs,

    Le 30.9.2010 j'ai suggéré:

    A ta place, je férais un essai avec un réseau sans WI-FI, correctement câblé.
    Essaie d'isoler le pb. Le plus probable c'est que tu as de micro (ou pas si "micro") coupures tans ton WIFI.
    Je pense que:

    1. tu devrais penser à "isoler" ton pb, comme objectif immédiat,
    2. c'est peu réaliste, et certainement ce sera très cher, de modifier une app. pour changer le système d'échange d'info qui est en format database sur un format "txt" + MD5 pour check d'intégrité.
    3. Tu peux essayer d'isoler le pb à niveau "code delphi" si tu compiles une version d'essai en mettant en oeuvre des structures try-except-else-end; et des messages d'erreur convénables. Ceci te donnera une idée exacte sur comment plante l'appli.

    Bonne chance!

  16. #16
    Invité régulier
    Profil pro Mur Mikael
    Inscrit en
    avril 2010
    Messages
    133
    Détails du profil
    Informations personnelles :
    Nom : Mur Mikael

    Informations forums :
    Inscription : avril 2010
    Messages : 133
    Points : 9
    Points
    9

    Par défaut RE

    Bonjour,

    Effectivement, j'ai essayé l'application sur un réseau câblé. Le résultat, est que je n'ai aucune erreur.

    Votre réflexion était correcte. Merci à vous deux

    Merci FDR2006 pour ton troisième point, c'est ce que j'essaierais de faire actuellement, c'est d'isoler le problème au niveau du code source delphi par des try-except.

    Le plus probable est que l'erreur parvient lors de l'envoi du fichier texte du poste local vers le serveur bd.
    Mais ce qui m'étonne est qu'un problème à ce niveau engendre le cassage des index des tables du poste local.

    A plus

  17. #17
    Membre habitué
    Profil pro
    Inscrit en
    octobre 2007
    Messages
    107
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations forums :
    Inscription : octobre 2007
    Messages : 107
    Points : 118
    Points
    118

    Par défaut

    Plusieurs choses :

    a) Pdxrbld peut-être lancé en batch de mémoire (à vérifier)

    b) Il n'est pas normal (sauf dans le cas d'un réseau WIFI...) d'avoir des problèmes récurrents d'index. C'est le plus souvent du à un réseau défaillant

    c) Réparer une table paradox ne devrait pas, selon moi, se faire en automatique car des enregistrements peuvent disparaître, il faut surveiller cette opération délicate. Ce que l'on peut automatiser c'est la vérification de l'intégrité des tables (différent donc d'une réparation) et la reconstruction des index.). Il me semble que Pdxrbld peut produire un fichier de log par exemple. (il existe aussi d'autrzes produits comme ChimneySweep payant)

    Mais ne vous épuisez pas, si votre réseau n'est pas stable tout ceci est voué à l'échec pour une base fichier comme Paradox. Les pistes pour sortir de cette situation sont connues : du client / serveur (mais grosses modifications à prévoir et problème tout de même si le réseau est réellement défaillant) ou plus radicalement le travail en TSE/VNC/Citrix bref sans échange réseau des données.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •