[WD9] Erreurs diverses lors de l'acces a mes fichiers HF
13 réponses
Emmanuel Haefele
Bonjour,
Je craque car sur l'un de nos sites j'ai différentes erreurs qui se
produisent lors de l'accès à nos fichiers HF et que vraiment je ne
comprends pas !
Exemple des erreurs les plus couramment rencontrées :
- Erreur : 70012 sur un HModifie
Une clé cherchée dans un noeud du fichier <s:\Repertoire\FICHIER.NDX> n'a
pas été trouvée. Vous devez réindexer votre fichier.
- Erreur : 70150 sur un HLitRecherchePremier
Impossible de se repositionner dans le fichier
<s:\Repertoire\FICHIER.NDX>.
Erreur : 70150
Impossible d'ouvrir le fichier <s:\Repertoire\FICHIER.NDX>.
Erreur 70037 sur un HAjoute
Le fichier <FICHIER> n'a pas été ouvert avec des droits en écriture.
Impossible d'effectuer l'opération.
L'aide de windev sur ces codes erreurs me dit :
<<<
70012: NOM DE CLÉ INCONNU
Le nom de la clé donné dans la fonction de gestion de fichier n'existe
pas. H.ErrIgnore est sans effet pour cette erreur.
Remarque perso : C'est un hModifie qui pose problème, aucun nom de clé
n'est passé à la fonction
>>>
<<<
70037: FICHIER NON MODIFIABLE
Tentative de modification sur un fichier non modifiable (read-only).
Remarque perso : Cette erreur est très ponctuelle, apparait et disparait
immédiatement après
>>>
<<<
70150: ERREUR SYSTÈME INATTENDUE
Erreur système inattendue. Répétez l'opération.
>>>>
N'importe quel fichier peut être touché, à chaque fois l'appli plante
brutalement et moi pendant ce temps je deviens fou car ça me pose de très
gros soucis au niveau de l'intégrité de la base. Ces erreurs peuvent ne
pas apparaitre durant 15 jours ou apparaitre 1 à 2 fois par semaine.
Le client me dit naturellement qu'il ne touche à rien sur le serveur et
que l'antivirus (Trend Micro) n'est pas en cause. Vraiment je ne sais plus
ou chercher car tout est ondulé, switch compris.
Est-ce que Trend Micro (que je ne connais pas) pourrait-être la cause ?
Même si tout est ondulé j'ai tendance également à penser que ça pourrait
être lié à des problèmes électriques. Une surtension pourrait être la
cause ?
L'outil d'administration de base de données SQLServer (SQL server enterprise manager) est très intuitif et facilement gérable. De plus on m'avait conseillé SQL server à l'époque d'où mon choix de l'époque. Mais je pense que maintenant je n'aurai pas peur non plus de le gérer avec du MySQL étant donné la qualité des outils d'administration mis à disposition pour ce système de base de données. J'avais tester avec Firebird mais je n'ai pas trouvé d'outils gratuits satisfaisants pour gérer ce type de base.
En espérant avoir répondu à vos questions.
"Eric Demeester" <eric+ a écrit dans le message de news:
dans (in) fr.comp.developpement.agl.windev, "Fredo MT" ecrivait (wrote) :
Bonjour,
Depuis 1 an j'ai changé mon système de base de données HF contre du SQL Server.
Question bête mais sérieuse (ce n'est pas un troll) : Tant qu'à migrer, as-tu des raisons précises d'avoir choisi SQL Server plutôt qu'un équivalent dans le monde du logiciel libre (MySQL ou PostGreSQL pour ce citer que les deux plus connus) ?
Amicalement,
-- Eric
Bonjour,
L'outil d'administration de base de données SQLServer (SQL server enterprise
manager) est très intuitif et facilement gérable. De plus on m'avait
conseillé SQL server à l'époque d'où mon choix de l'époque. Mais je pense
que maintenant je n'aurai pas peur non plus de le gérer avec du MySQL étant
donné la qualité des outils d'administration mis à disposition pour ce
système de base de données. J'avais tester avec Firebird mais je n'ai pas
trouvé d'outils gratuits satisfaisants pour gérer ce type de base.
En espérant avoir répondu à vos questions.
"Eric Demeester" <eric+usenet@galacsys.net> a écrit dans le message de news:
ncea2213a38ft9m51cl8p497m8vg4rvkls@4ax.com...
dans (in) fr.comp.developpement.agl.windev, "Fredo MT"
<frederic@nospam_mont-tauch.com> ecrivait (wrote) :
Bonjour,
Depuis 1 an j'ai changé mon système de base de données HF contre du SQL
Server.
Question bête mais sérieuse (ce n'est pas un troll) : Tant qu'à migrer,
as-tu des raisons précises d'avoir choisi SQL Server plutôt qu'un
équivalent dans le monde du logiciel libre (MySQL ou PostGreSQL pour ce
citer que les deux plus connus) ?
L'outil d'administration de base de données SQLServer (SQL server enterprise manager) est très intuitif et facilement gérable. De plus on m'avait conseillé SQL server à l'époque d'où mon choix de l'époque. Mais je pense que maintenant je n'aurai pas peur non plus de le gérer avec du MySQL étant donné la qualité des outils d'administration mis à disposition pour ce système de base de données. J'avais tester avec Firebird mais je n'ai pas trouvé d'outils gratuits satisfaisants pour gérer ce type de base.
En espérant avoir répondu à vos questions.
"Eric Demeester" <eric+ a écrit dans le message de news:
dans (in) fr.comp.developpement.agl.windev, "Fredo MT" ecrivait (wrote) :
Bonjour,
Depuis 1 an j'ai changé mon système de base de données HF contre du SQL Server.
Question bête mais sérieuse (ce n'est pas un troll) : Tant qu'à migrer, as-tu des raisons précises d'avoir choisi SQL Server plutôt qu'un équivalent dans le monde du logiciel libre (MySQL ou PostGreSQL pour ce citer que les deux plus connus) ?
Amicalement,
-- Eric
Emmanuel Haefele
"VincentC" a écrit :
Bonjour Vincent,
j'avais des soucis de lenteur sur des tables HF avec quelques centaines de millier d'enregistrement. j'ai profité de la migration 5.5 vers 9 pour passer en HF C/S.
Pour l'instant, ça va mieux. et la migration (vers HF C/S) ne prend pas beaucoup de temps. (à part des pb avec des tables qui ont des noms réservé du type user, group ...
Pour l'avoir fait moi-même je suis entièrement d'accord avec toi mais par contre la semaine dernière nous sommes tombé sur un problème très particulier, voir mon post "[WD9] Dysfonctionnement en HF C/S sur la gestion des blocages ?"
C'est peux être un essai à faire. Question timing, il m'a fallu beaucoup plus de temps pour passer de 5.5 à 9 que de HF Classic à HF C/S.
Effectivement il n'y a pas photo puisqu'encore aujourd'hui j'apporte des corrections à ma version 9.
Est-ce que tes problèmes ne serait pas lier à des pics d'utilisation réseau ? ou des pics d'utilisation du serveur (CPU à 100%, pas assez de mémoire, etc ... )?
L'idée est intéressante mais difficile à contrôler. Je vais essayer de suivre un peu cette piste.
Ca me rappelle mes problèmes avec paradox quand il y a avait trop d'E/S les index crashés.
Ca aussi c'est intéressant mais moins évident puisque ce sont parfois des fichiers qui ne bougent pas beaucoup au niveau des index et de plus qui ne sont pas très volumineux.
Merci pour les pistes
Amicalement,
Emmanuel Haefelé.
"VincentC" <VNO.SPAM_perso@free.Fr> a écrit :
Bonjour Vincent,
j'avais des soucis de lenteur sur des tables HF avec quelques centaines
de millier d'enregistrement. j'ai profité de la migration 5.5 vers 9
pour passer en HF C/S.
Pour l'instant, ça va mieux. et la migration (vers HF C/S) ne prend pas
beaucoup de temps. (à part des pb avec des tables qui ont des noms
réservé du type user, group ...
Pour l'avoir fait moi-même je suis entièrement d'accord avec toi mais par
contre la semaine dernière nous sommes tombé sur un problème très
particulier, voir mon post "[WD9] Dysfonctionnement en HF C/S sur la
gestion des blocages ?"
C'est peux être un essai à faire. Question timing, il m'a fallu
beaucoup plus de temps pour passer de 5.5 à 9 que de HF Classic à HF
C/S.
Effectivement il n'y a pas photo puisqu'encore aujourd'hui j'apporte des
corrections à ma version 9.
Est-ce que tes problèmes ne serait pas lier à des pics d'utilisation
réseau ? ou des pics d'utilisation du serveur (CPU à 100%, pas assez de
mémoire, etc ... )?
L'idée est intéressante mais difficile à contrôler. Je vais essayer de
suivre un peu cette piste.
Ca me rappelle mes problèmes avec paradox quand il y a avait trop d'E/S
les index crashés.
Ca aussi c'est intéressant mais moins évident puisque ce sont parfois des
fichiers qui ne bougent pas beaucoup au niveau des index et de plus qui ne
sont pas très volumineux.
j'avais des soucis de lenteur sur des tables HF avec quelques centaines de millier d'enregistrement. j'ai profité de la migration 5.5 vers 9 pour passer en HF C/S.
Pour l'instant, ça va mieux. et la migration (vers HF C/S) ne prend pas beaucoup de temps. (à part des pb avec des tables qui ont des noms réservé du type user, group ...
Pour l'avoir fait moi-même je suis entièrement d'accord avec toi mais par contre la semaine dernière nous sommes tombé sur un problème très particulier, voir mon post "[WD9] Dysfonctionnement en HF C/S sur la gestion des blocages ?"
C'est peux être un essai à faire. Question timing, il m'a fallu beaucoup plus de temps pour passer de 5.5 à 9 que de HF Classic à HF C/S.
Effectivement il n'y a pas photo puisqu'encore aujourd'hui j'apporte des corrections à ma version 9.
Est-ce que tes problèmes ne serait pas lier à des pics d'utilisation réseau ? ou des pics d'utilisation du serveur (CPU à 100%, pas assez de mémoire, etc ... )?
L'idée est intéressante mais difficile à contrôler. Je vais essayer de suivre un peu cette piste.
Ca me rappelle mes problèmes avec paradox quand il y a avait trop d'E/S les index crashés.
Ca aussi c'est intéressant mais moins évident puisque ce sont parfois des fichiers qui ne bougent pas beaucoup au niveau des index et de plus qui ne sont pas très volumineux.
Merci pour les pistes
Amicalement,
Emmanuel Haefelé.
VincentC
Emmanuel Haefele a émis l'idée suivante :
Ca aussi c'est intéressant mais moins évident puisque ce sont parfois des fichiers qui ne bougent pas beaucoup au niveau des index et de plus qui ne sont pas très volumineux.
Mes pb avec paradox, n'était pas dépendant de la taille ( je les ai eu sur des fichiers de quelques centaines d'enrg) , mais uniquement de l'intensité des ajout/suppression. Pour éviter les composants du style Check&Repair à chaque démarrage de l'appli, je n'ai eu qu'une alternative : Paradox -> DataPump -> Interbase.
Merci pour les pistes
De rien
Amicalement,
De même,
Emmanuel Haefelé.
VincentC.
Emmanuel Haefele a émis l'idée suivante :
Ca aussi c'est intéressant mais moins évident puisque ce sont parfois des
fichiers qui ne bougent pas beaucoup au niveau des index et de plus qui ne
sont pas très volumineux.
Mes pb avec paradox, n'était pas dépendant de la taille ( je les ai eu
sur des fichiers de quelques centaines d'enrg) , mais uniquement de
l'intensité des ajout/suppression. Pour éviter les composants du style
Check&Repair à chaque démarrage de l'appli, je n'ai eu qu'une
alternative : Paradox -> DataPump -> Interbase.
Ca aussi c'est intéressant mais moins évident puisque ce sont parfois des fichiers qui ne bougent pas beaucoup au niveau des index et de plus qui ne sont pas très volumineux.
Mes pb avec paradox, n'était pas dépendant de la taille ( je les ai eu sur des fichiers de quelques centaines d'enrg) , mais uniquement de l'intensité des ajout/suppression. Pour éviter les composants du style Check&Repair à chaque démarrage de l'appli, je n'ai eu qu'une alternative : Paradox -> DataPump -> Interbase.
