Discussion :

[Magnus]

Bonjour,

Je dispose d'une DB dont une des tables (nommée DETAIL_RESA est corrompue), par ex quand on fait :

Code :

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

select count(*) from DETAIL_RESA

, on obtient le message d'erreur suivant :

internal gds software consistency check (decompression overan buffer (179))

Je ne peux pas faire de backup ou de validation sur cette base.

Par conséquent, voici ce que j'ai fait :
j'ai créé une nouvelle base .gdb
j'ai appliqué le script de création des fonctions UDF, des index, des tables, etc. généré par IBConsole sur cette nouvelle base
j'ai généré le contenu de toutes les tables de la base "cassée" dans des fichiers .sql (grâce à une application que j'ai développé) ; y compris pour la table corrompue
j'ai chargé les fichiers .sql un à un dans la nouvelle base précédente (grâce à mon application précédente)

CONCLUSION : je n'ai aucune erreur durant cette procédure mais lorsque j'utilise cette nouvelle base, tout accès à la table DETAIL_RESA qui était corrompue provoque un message d'erreur :

impossible de modifier un ensemble de données en lecture seule

IDEE : j'ai appliqué cette même cinématique sur une autre base non corrompue pour valider son fonctionnement et aussi surprenant que cela paraisse, ça engendre le même problème.

AUTRE IDEE : sur une base non corrompue si j'applique la même procédure MAIS que j'utilise IBExpert pour générer les fichiers .sql lors de la 3ème étape alors la nouvelle base fonctionne parfaitement.

CONCLUSION GENERALE : pour moi, le fait que la nouvelle base ne fonctionne pas vient du fait que les fichiers .sql générés par IBExpert sont différents de ceux générés par mon application. Hormis la syntaxe, c'est-à-dire des espaces entre les virgules, etc. ces fichiers sont identiques en nombre de lignes, ils ont le même format :

Code :

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

INSERT INTO DETAIL_RESA (det_codresa, det_noenreg, ...) VALUES (20, 12, ...);

Pour vous d'où vient cette différence ?

Merci par avance (et de votre patience pour m'avoir lu).

[qi130]

Un problème de droits ? (grant)

[Barbibulle]

Je suppose que vous n'etes pas loggé avec le même user lors de la création de votre base avec votre appli et lors de la création avec IBExpert.

D'ou un problème de droit.

[Magnus]

Je pensais aussi à cette éventualité mais non. En fait, je viens de trouver mais je ne suis pas sûr de la raison
Apparemment ça venait du fait que j'invoquais la méthode

Code :

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

DateTimeToString()

sur des dates qui étaient certaines fois à NULL. Dans ce cas, le résultat de l'appel est : '12/30/1899 00:00:00' et si cela n'implique pas d'erreur lors du chargement, tout semble indiquer que la manipulation des données n'est plus possible...

Une fois cette modification apportée à la génération des fichiers .sql alors la nouvelle base créée fonctionne à merveille.

Merci de ta participation qi130

[Magnus]

Après avoir effectué des tests complémentaires je peux maintenant affirmer que c'est effectivement la méthode DateTimeToString invoquée sur des valeurs à NULL qui posait problème pour la manipulation de la nouvelle base !

Quand je pense au temps que j'ai perdu (et vous aussi) à déterliner l'origine du problème. Nan, vraiment il faudrait une doc sur InterBase.

Merci à tous.

[Barbibulle]

Ah oui en effet c'est un message des composants Delphi/BC++ et non interbase....

Je suppose que la consultation des tables qui posent problemes avec IBExpert passaient sans problemes...

[Magnus]

Je ne suis pas sûr de comprendre votre remarque :

Je suppose que la consultation des tables qui posent problemes avec IBExpert passaient sans problemes...

Sous IBConsole, j'arrive à voir les enregistrements des tables corrompues mais je ne peux pas faire de

Code :

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

select count(*) ...

; ceci dit c'est effectivement mieux que sous IBExpert.

[Barbibulle]

internal gds software consistency check (decompression overan buffer (179))

C'est un message d'interbase. Votre base à un problème c'est clair.

impossible de modifier un ensemble de données en lecture seule

Ca par contre c'est un message de la VCL. Pas de lien avec un éventuel problème de grant ou identification comme on a pu le supposer en premier.

Et ma remarque portait sur ce second message. Donc sur vos tables non corrompues. Je disais que vous auriez essayé sous IBConsole ou IBExpert ca aurait bien fonctionné. Ce qui nous aurait fait dire que c'était votre programme qui avait un problème.

[Magnus]

D'accord je vous suis.

Je vous avouerai que je croyais comme vous que le 2ème message était engendré suite à une erreur de programmation et non à une corruption de la BD.

J'ai cru à cette hypothèse jusqu'à ce que le chargement des fichiers .sql générés grâce à IBExpert rende l'application à nouveau fonctionnelle. A partir de là, j'ai compris que la différence résidait dans les fichiers .sql générés, j'ai alors pu déterminer la cause de mon erreur et ainsi réparer la base cassée.

MAIS pour moi il existe un réel mystère autour du fait que si des dates ont la valeur '12/30/1899 00:00:00' alors un message est généré par Delphi. Je n'ai pas lu tout le code du programme mais aucun test n'est fait sur cette date précise alors d'où vient le problème ? D'Interbase ?

Toujours j'ai remarqué 2-3 faits surprenants : dans une requête INSERT, un champ VARCHAR peut avoir comme valeur '' ou NULL mais un champ DOUBLE PRECISION (par ex) ne peut pas valoir '' (heureusement NULL est excepté).
D'autre part, les formats de date suivants sont acceptés 'YYYY-MM-DD' ou 'mm/dd/yyyy' mais pas 'dd/mm/yyyy'.

Bref, une fois le problème identifié, j'arrive à le résoudre (des fois grâce à vous ) mais il arrive que je ne puisse pas expliquer la raison.

[Barbibulle]

MAIS pour moi il existe un réel mystère autour du fait que si des dates ont la valeur '12/30/1899 00:00:00' alors un message est généré par Delphi. Je n'ai pas lu tout le code du programme mais aucun test n'est fait sur cette date précise alors d'où vient le problème ? D'Interbase ?

Cette date est la date de référence de TDateTime. Un TDateTime n'est autre qu'un type DOUBLE. La partie entière de ce double représente le nombre de jour depuis cette date et la partie décimale représente l'heure.

Donc 0 est représenté par la date '30/12/1899 00:00:00'

Cette date est une date vadide sous IB car il accepte des dates comprisent entre le 1/1/100 et 29/2/32768 ( attention au bug de l'an 32768 )

Maintenant pourquoi dans votre application ca pose problème je ne sais pas.

Toujours j'ai remarqué 2-3 faits surprenants : dans une requête INSERT, un champ VARCHAR peut avoir comme valeur '' ou NULL mais un champ DOUBLE PRECISION (par ex) ne peut pas valoir '' (heureusement NULL est excepté).

La raison est simple et l'erreur que vous commettez est de croire que NULL est une valeur.

NULL est l'absence de valeur, c'est un indicateur à part (en plus) de la valeur du champ (colonne.)

C'est vrai que par abus de langage on dit en effet qu'on met à null la valeur. Mais celà n'empèche qu'il faut garder en mémoire que NULL n'est pas une valeur.


Ainsi une chaine peut avoir pour valeur 'AZE...' et également '' qui est une chaine de caractère (même si elle est particulière car vide c'est une chaine de caractère)
Si une colonne a pour valeur '' c'est que vous avez affecté la VALEUR chaine vide. Si l'indicateur est à NULL celà veux dire qu'il n'y a pas de valeur d'affecté (donc même pas une chaine vide).

Pour ce qui est des autres types INTEGER, DOUBLE l'intéret du nul est encore plus grand et je dirais que l'équivallent de la chaine vide c'est la valeur 0. Et l'indicateur NULL indique qu'il n'y a pas de valeur d'affecté (donc même pas 0)...

Dernier exemple DATE si la valeur est optionnelle qu'allez vous mettre dans date pour dire que vous ne renseignez pas la date ? '' n'est pas une date valide c'est une chaine vide... Ceux qui n'utilisent pas l'indicateur NULL utilisaient arbitrairement une date improbable qu'ils testaient pour déterminé si la date a été saisie ou non...
Bref on voit bien l'utilité de l'indicateur NULL. Et surtout la différence entre '' et NULL.

D'autre part, les formats de date suivants sont acceptés 'YYYY-MM-DD' ou 'mm/dd/yyyy' mais pas 'dd/mm/yyyy'.

Oui ou YYYY/MM/DD ou MM-DD-YYYY. Mais celà n'a aucunne importance si vous utilisez correctement la VCL. Comme expliqué plus haut les dates sont représentés dans des doubles, l'affichage sous une forme date n'est que de la présentation.
Ne mettez pas de Date en dur dans vos ordres SQL et vous n'aurez jamais de problème. (Utilisez toujours des requetes paramétrèes) Et pour ce qui est de l'affichage à l'écran, si vous utilisez les composants orientés DB ceux ci prennent en compte le paramétrage régionnale du poste et donc affiche correctement les dates.

[Magnus]

Avec vos précisions je comprends mieux certaines choses...

Ceci dit, j'ai encore quelques remarques 8)

Vous expliquez qu'une date est un DOUBLE représentant l'écart depuis la date de référence '30/12/1899 00:00:00' mais alors comment savoir quand je passe en mode débug à quelle date correspond au format humain le timestamp 38 467 par ex ? En utilisant une fonction du style TimeToStr ?

Pour ce qui est d'utiliser des requêtes paramétrées afin de résoudre les problèmes de formats de dates, je vais suivre votre conseil et faire des recherches sur les requêtes paramétrées (ça vous évitera de poster une nième fois ce qui a été dit et redit ).

Merci encore pour cette mine d'infos

[Barbibulle]

Vous expliquez qu'une date est un DOUBLE représentant l'écart depuis la date de référence '30/12/1899 00:00:00' mais alors comment savoir quand je passe en mode débug à quelle date correspond au format humain le timestamp 38 467 par ex ? En utilisant une fonction du style TimeToStr ?

C'est valable pour les TDateTime (spécifique à la VCL/CLX) le format TimeStamp est un peu différent il me semble qu'il est composé d'un record de deux integer.
En temps normal vous n'avez pas à utiliser la vrai valeur (sous forme de double) car il existe une multitude de fonctions attachés aux TDateTime pour les manipuler dont la DateToStr qui convertis votre TDateTime en chaine de caractère au format défini dans les paramètrage régionnale du poste.

Bref ce qu'il faut retenir c'est surtout qu'on enregistre pas une date dans un format donné (vu quelle est transformée en double ou plusieurs entiers). Le problème du format est le plus souvant lié à l'environnement.
Par exemple si vous utilisez la VCL/CLX et les TDateTime avec les composants, ceux ci afficheront vos dates en tenant compte du paramétrage du poste. Donc un poste paramétré en francais aurra une date de type JJ/MM/AAAA un poste configuré en anglais MM/JJ/AAAA.