Repérer un enregistrement défectueux

Repérer un enregistrement défectueux - SQL/NoSQL - Programmation

Marsh Posté le 23-07-2008 à 22:06:22    

Salut tout le monde,
Je voudrais s'il vous plait connaitre un moyen pour repérer l'enregistrement défectueux au cours d'une opération de mise à jour pour ensuite le préciser dans le message.
Exemple: Erreur MAJ enregistrement n° 22  
Comment pourrais je réaliser cela sous oracle ?

Reply

Marsh Posté le 23-07-2008 à 22:06:22   

Reply

Marsh Posté le 24-07-2008 à 10:58:08    

Alors une idée ?

Reply

Marsh Posté le 24-07-2008 à 13:25:39    

bonjour, je voudrais savoir ce que va me répondre ma boule de crystal

Reply

Marsh Posté le 24-07-2008 à 14:58:34    

Ton ironie m'aide beaucoup merci  :)
En, fait j'ai trouvé une solution simple traiter séquenciellement les enregistrements de la table pour repérer facilement la source du problème mais je cherchais un autre moyen moins long car mes connaissances en PL/SQL sont limitées.

Reply

Marsh Posté le 24-07-2008 à 15:44:14    

En fait c'est le terme employé  
=> ... l'enregistrement défectueux ...
qui me parait ténébreux !?
 
C'est quoi comme erreur au juste ? une erreur de containtes d'intégrité ?
Une erreur de type de données (tentative d'update d'un champ numérique  avec une chaine de caractères ...)
 
Car moi aussi je vois rien dans ma boule de cry..istal ;-)


---------------
il n'y a pas que le VTT dans la vie, il y a le Snowboard aussi ...
Reply

Marsh Posté le 24-07-2008 à 16:31:28    

Ah ok plus une interruption inattendue du système (crash,coupure de courant ..),en fait c'est la manière de repérer l'enregistrement problématique qui m'intéresse pour reprendre la mise à jour plus tard à ce niveau.
Car l'update classique s'effectue par lot,je pensais qu'il y avait un moyen plus simple d'y arriver que la boucle +boolean
En tout cas merci pour vos réponses.

Reply

Marsh Posté le 24-07-2008 à 16:36:35    

si c'est pour récupérer d'un crash système / coupure de courant, passe par une transaction.
un fichier de log ne pourra jamais à coup sûr être à jour au moment du crash (c'est pas parceque tu écris dans une trace qu'elle est flushée sur le disque systématiquement notamment).
 
pour cette raison, transaction et commit. ça a foiré ? pas de problème, tu reprends depuis le début, y'a pas une ligne qui est passée de toute façon.
 
ensuite, pour des problèmes de contrainte/type/etc. à part faire une trace ou tester chaque valeur de chaque champ à la main avant la tentative d'insertion, y'a pas de solution miracle...

Reply

Marsh Posté le 24-07-2008 à 16:41:23    

MagicBuzz a écrit :

si c'est pour récupérer d'un crash système / coupure de courant, passe par une transaction.
un fichier de log ne pourra jamais à coup sûr être à jour au moment du crash (c'est pas parceque tu écris dans une trace qu'elle est flushée sur le disque systématiquement notamment).
 
pour cette raison, transaction et commit. ça a foiré ? pas de problème, tu reprends depuis le début, y'a pas une ligne qui est passée de toute façon.
 
ensuite, pour des problèmes de contrainte/type/etc. à part faire une trace ou tester chaque valeur de chaque champ à la main avant la tentative d'insertion, y'a pas de solution miracle...


 
Voila c'est ça que je voulais éviter je pensais que les enregistrements traités avant le crash ou toute autre interruption étaient sauvegardés merci pour ces éclaircissements.

Reply

Marsh Posté le 24-07-2008 à 16:59:50    

non, si tu travailles bien en mode transactionnel, aucun enreistrement n'est réellement sauvegardé tant que t'as pas fait un commit de façon explicite.
 
par contre, souvent il faut découper en plusieurs "lots" les mises à jour, car le rollback segment n'est pas extensible à l'infini et fini par claquer (genre après 500 000 modifications, si t'as toujours pas commité, t'as intérêt à commencer à serrer les fesses ;))

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed