Discussion :

[elsuket]

le code reste lisible et facile à maintenir

Écrivez la requête, et regardez la différence avec votre traitement : y'a pas photo

@++

[DEV-10]

Écrivez la requête, et regardez la différence avec votre traitement : y'a pas photo

@++

Qu'est ce que tu veux dire par "y'a pas photo " ?

J'ai écrit un autre post pour toi ci-dessous concernant le commit et rollback. L'as tu vu ?

[elsuket]

En passant, pour ma procédure actuelle qui est déjà écrite et que mes tables ont été créer au fur et à mesure, est-ce que ça serait possible de prendre toute la procédure au complet et l'encapsuler dans une transaction

Rien ne s'y oppose, mais vous devez veiller à ce que votre transaction soit la plus courte possible, de sorte à verrouiller le moins de ressources possible et en un minimum de temps.

Qu'est ce que tu veux dire par "y'a pas photo " ?

Le traitement pas requête comme vous te l'a conseillé SQLPro, que je rejoins, sera forcément plus simple que de multiples requêtes entre lesquelles vous stockez un résultat intermédiaire.

N'aie pas peur de poster ton code, nous pouvons t'aider à le simplifier

@++

[DEV-10]

Rien ne s'y oppose, mais vous devez veiller à ce que votre transaction soit la plus courte possible, de sorte à verrouiller le moins de ressources possible et en un minimum de temps.

Si j'utilise ta procédure de cration et de suppression de table, je présume le faire comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
-- Début de ma procédure
......point A....................
..........................
exec ps_CreeSupprimeTable 1
.................................
.................................
........point B.........................
ps_CreeSupprimeTable 0
 
-- Fin de ma procesdure

juste pour m'éclaircir encore mieux :
- si une panne arrive lorsque ma procédure est au point A, ca ne dérange pas car rien n'a été crée encore

- Au point B, la procédure ps_CreeSupprimeTable a été déja appelée pour faire la création des tables. Si une panne arrive à ce point, est-ce que la partie ELSE de la procédure ps_CreeSupprimeTable sera exécuté parreil ?

Si oui, le tout est correct selon mon besoin
si non, les tables qu'elle vait créer vont rester sur la bases de données. Ce que je ne souhaitais pas.

Merci.

[elsuket]

Si tu es sous SQL Server 2000, tu dois vérifier la valeur que te retourne la fonction @@ERROR : si elle te retourne une valeur différente de 0, c'est qu'il y a eu un problème.
Tu peux alors décider de défait ce qui a été fait jusque là (ROLLBACK), ou continuer.

Si tu travailles sous SQL Server 2005 ou 2008, je te conseille vivement d'utiliser un TRY...CATCH

@++

[DEV-10]

Si tu es sous SQL Server 2000, tu dois vérifier la valeur que te retourne la fonction @@ERROR : si elle te retourne une valeur différente de 0, c'est qu'il y a eu un problème.
Tu peux alors décider de défait ce qui a été fait jusque là (ROLLBACK), ou continuer.

Si tu travailles sous SQL Server 2005 ou 2008, je te conseille vivement d'utiliser un TRY...CATCH

@++

je suis sur SQL 2000. Ils disent que @@ERROR retounre le numéro d'erreur pour la dernière instruction Transact-SQL exécutée. Mais si il y a eu erreur dans une instruction avant la dernière et l'exécution avait continuer parreil alors que la toute dernière instruction n'avait pas d'erreur ?

@@ERROR (Transact-SQL)

Retourne le numéro d'erreur pour la dernière instruction Transact-SQL exécutée.

[elsuket]

Il te faut tester ce que retourne @@ERROR après chaque instruction ...
Tu continues si c'est 0

@++

[DEV-10]

Il te faut tester ce que retourne @@ERROR après chaque instruction ...
Tu continues si c'est 0

@++

dans ce cas, si notre procédure stockée contient 500 lignes, il faut tester 500 fois, et plus la taille grandit, plus les tests deviennent importants en terme de temps d'exécution.

Est-ce que tu pense que c'est la raison qui a amené les gens à utiliser les tables temporaires du système ?

[elsuket]

dans ce cas, si notre procédure stockée contient 500 lignes, il faut tester 500 fois, et plus la taille grandit, plus les tests deviennent importants en terme de temps d'exécution.

Un test d'égalité sur deux entiers est extrêmement rapide.
Tu peux centraliser ton, code de gestion des erreurs en fin de procédure à l'aide d'un GOTO

Est-ce que tu pense que c'est la raison qui a amené les gens à utiliser les tables temporaires du système ?

A mon sens cela n'a pas de rapport. Les tables temporaires sont utilisées par rapport à leur nom, qui fait penser qu'elles ne sont pas persistées, ce qui est faux.

@++