Discussion :

[bstevy]

Bonjour à tous,


Je suis en train d'étudier un scrit, et j'ai un peu du mal à envisager un cas de plantage. J'ai des exeptions dans tous les sens, mais une en particulier est censée arreter mon script en plein milieu si ca se produit et j'aimerai bien la produire cette erreur ^^

Voici mon cas

0-J'ai une table EXTRACTION dans laquelle j'ai des numéros de contrats à extraire, et un booleen 0 ou 1 qui signifie respective "a extraire" et "extrait" (PK sur mon contrat)
1-je créé un curseur sur ma table EXTRACTION et je récupere la liste des contrat "a extraire"
2-j'utilise une fonction pour retrouver des infos sur mes contrats
3-si j'ai pas d'info, je reviens en 1 (CONTINUE)
4-Si j'ai des info, je mets à jours, via une fonction, ma table EXTRACTION en remplacant le 0 par un 1
5-Si y'a une erreur pendant cette maj, on stop tout !
6-fin de la boucle, je reviens en 1

C'est ce point 5 qui m'embete... comment faire pour que cette fonction plante. Derriere, il y a un simple update; et etant donné que c'est la table de mon curseur, elle existe forcement, la ligne existe forcement... j'arrive pas à penser à un cas où ca pourrait planter. Vous auriez une idée ?

Merci d'avance.

Steven

[mnitu]

Ca peut planter en deux situations :

1. Comme votre traitement modifie la même table qu'il a lu il est possible de rencontrer l'erreur snapshot too old. En pratique cela arrive rarement.
2. Si la lecture est fait sans verrouillage des données il est possible en principe de supprimer via une autre session un enregistrement sélectionné par votre traitement pendant que le traitement se déroule. De cette façon la mise à jour de l'enregistrement pourrais échouer si vous testez que la mise à jour a bien modifié un et seulement et unique enregistrement.

Mais votre façon de raisonner est typique pour une programmation classique. Sous SQL vous manipulez des ensembles des données et dans l'idéal vous devez ramener en même temps le contenu de la table d'extraction et les informations des autres tables (recherche des informations) via des jointures. Ensuite l'ensemble ainsi constitué devrai faire l'objet d'un traitement par lot.

Dans votre présentation il manque une partie qui indique ce que vous allez faire avec les informations ramène par votre fonction. Tel que vous le décrivez votre traitement devrait se réduire à un simple

Code :

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

1
2
3
4
5
6
7
8
 
Update extraction
  Set status = 'extrait'
Where status = 'a extraire'
  And exists (Select Null
                     From autres_tables
                   Where divers_restrictions
                 )

ce qui représente déjà un code plus robuste et fiable en même temps.

[bstevy]

Hmm, y'a un truc que je comprends pas bien dans ce que vous venez de dire...

Mais votre façon de raisonner est typique pour une programmation classique. Sous SQL vous manipulez des ensembles des données et dans l'idéal vous devez ramener en même temps le contenu de la table d'extraction et les informations des autres tables (recherche des informations) via des jointures. Ensuite l'ensemble ainsi constitué devrai faire l'objet d'un traitement par lot.

Est ce que vous sous-entendez que derriere cette programmation procédurale, Oracle va faire de l'ensembliste et traiter les lignes de mon curseur en parallele ?
J'interprete peut etre mal (c'est pas toujours évident sur internet, desole), mais pour moi, le programme que j'ai décris est bien un bon vieux programme procédural, sans aucune notion ensembliste à l'interieur. Mais c'est pas moi qui l'ai codé :'( et on me demande de le modifier.

Pour vous situer rapidement le contexte : je suis arrivé y'a pas longtemps, et toute la base tourne avec des fonctions "unitaire", c'est à dire qu'elles mettent à jour ou n'extraient qu'une ligne à la fois... je pete un cable moi qui vient de teradata et qui ai l'habitude de travailler en ensembliste.


Bref, pour plus d'info sur mon programme, au point 4, si j'ai des info, en fait, je les stock dans une variable, et à la fin de ma boucle, je parcours cette variable pour ecrire un fichier avec les données récupérées. (oui, j'adore faire les choses en double )




Donc à part le cas où y'aurait une concurence d'acces, ca risque pas de planter, on est bien d'accord...
Une question à ce sujet, imaginons que j'ai des contracts de 1 à 10. Je genere mon curseur, et je commence mes boucles... si pendant ce temps, je fais un

Code :

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

update set ID = ID*100

qu'est ce qui se passe au niveau de mon curseur ?
Imaginons qu'il en était à l'enregistrement 5, le suivant sera 6 et il plante car ca n'existe plus, ou il se met à jour automatiquement, et va chercher le 600 ?

[mnitu]

Oui c'est bien ça "un bon vieux programme procédural" qui "tourne avec des fonctions "unitaire"". Les gens qui font ça sont les vieux programmeurs qui n'ont jamais compris ce que c'est les bases relationnelles et le SQL et les jeunes formatés à la programmation objet.
Concernant votre autre question: il se passera rien. Votre curseur est marqué avec le SCN d'ouverture et verra les données tel qu'elles était à cet moment. Pour cela Oracle utilise son fameux mécanisme de "multi-versioning" en se basant sur l'information stocké dans les segments d'undo. Si l'information d'origine n'est plus disponible une erreur de type "snapshot too old" sera levée.