Comment éviter la “division par zéro” erreur SQL?

J'ai ce message d'erreur:

Msg 8134, Niveau 16, État 1, Ligne 1 erreur de division par zéro rencontrés.

Quelle est la meilleure façon d'écrire du code SQL de sorte que je ne verrai jamais ce message d'erreur?

Je pourrais le faire de la façon suivante:

  • Ajouter une clause where pour que mon diviseur n'est jamais nulle

Ou

  • Je pourrais ajouter une instruction du cas, de sorte qu'il existe un traitement spécial pour le zéro.

Est la meilleure façon d'utiliser un NULLIF clause?

Est-il de meilleure façon, ou comment cela peut-il être appliqué?

  • Peut-être certains de validation des données est dans l'ordre.
InformationsquelleAutor Henrik Staun Poulsen | 2009-05-14
  1. 602

    Afin d'éviter une Division par zéro" de l'erreur que nous avons programmé comme ceci:

    Select Case when divisor=0 then null
Else dividend / divisor
End ,,,

    Mais ici c'est tellement plus agréable façon de le faire:

    Select dividend / NULLIF(divisor, 0) ...

    Maintenant, le seul problème est de se rappeler l'NullIf peu, si j'utilise la touche'/'.

    • Une bien belle Façon de faire "Select dividend / nullif(diviseur, 0) ..." pauses si le diviseur est NUL.
    • Ce n'est pas vrai du tout. Êtes-vous sûr de ne pas utiliser accidentellement IsNull au lieu de NullIf? Essayez-le vous-même! SELECT Value,1/NullIf(Value,0)FROM(VALUES(0),(5.0),(NULL))x(Value); À moins que par "sauts" tu veux dire que renvoie une valeur NULL? Vous pouvez convertir ce que vous voulez avec IsNull ou Coalesce.
    • c'est vrai... essayez d'exécuter ... sélectionnez 1/nullif(null,0) ... vous obtenez "Le type du premier argument pour NULLIF ne peut pas être la constante NULL parce que le type du premier argument doit être connu." Gérer cela à l'aide de "fusionner(FieldName,0)" ... par exemple, sélectionnez 1/nullif(coalescer(null,0),0)
    • Je ne peux pas dire si vous êtes d'accord avec moi ou de discuter avec moi.
    • Regardez de plus près à l'erreur que vous avez obtenu. Oui, SELECT 1 / NULLIF(NULL, 0) échoue, mais c'est parce que NULLIF() besoins de connaître le type du premier argument. Cette altération exemple fonctionne très bien: SELECT 1 / NULLIF(CAST(NULL AS INT), 0). Dans la vraie vie, vous allez d'approvisionnement d'une colonne de table de NULLIF() plutôt qu'un NULL constante. Depuis des colonnes de la table ont connu les types de données, cela fonctionne aussi très bien: SELECT 1 / NULLIF(SomeNullableColumn, 0) FROM SomeTable.
    InformationsquelleAutor Henrik Staun Poulsen
  2. 169

    Dans le cas où vous voulez retourner à zéro, dans le cas d'un zéro devision qui allait se passer, vous pouvez utiliser:

    SELECT COALESCE(dividend / NULLIF(divisor,0), 0) FROM sometable

    Pour chaque diviseur de zéro, vous obtiendrez un zéro dans le jeu de résultats.

    • Certains tests de révéler qui FUSIONNENT est légèrement plus lent que ISNULL. Toutefois, se rejoignent dans les normes est donc plus portable.
    • Si quelqu'un n'est pas d'obtenir instantanément pourquoi cela fonctionne, NULLIF(d,0) renvoie NULL si la valeur de d est de 0. En SQL, en divisant par la valeur NULL renvoie la valeur NULL. L'Fusionnent remplace la résultante NULLE en 0.
    • Notez également qu'il renvoie 0 quand un dividende ou d'un diviseur sont NULLES alors que par le standard, il serait de retour la valeur NULL.
    • VEUILLEZ! Je suis choqué que cela devient 71 upvotes! La Division par zéro n'est pas défini et doit JAMAIS retour à ZÉRO! J'ai très rarement downvote, mais c'est vraiment de la merde! Au moins, veuillez supprimer les fusionner, puis la division renvoie la valeur NULL au lieu de Zéro, c'est mieux.
    • Alors que je suis d'accord avec votre argument, veuillez noter qu'il y a des cas qu'on se soucie plus de ce qui est statistiquement correct que mathématiquement correct. Dans certains cas, lors de l'utilisation de fonctions statistiques, 0 ou 1 est un résultat acceptable lorsque le diviseur est égal à zéro.
    • Faire des hacks comme cela a coûté de l'argent aux consommateurs, les gens perdus des emplois et, éventuellement, mettre des vies en danger. Ce type de réponse ne doit jamais être accepté dans n'importe quelle forme. Si vous souhaitez un rendement de 0 (ou 1) alors que vous êtes en train de faire quelque chose de mal ou de se poser la mauvaise question. (Rien / 0) Si c'est réellement le 0 puis vous faites quelque chose de mal et il retourne une erreur comme il se doit. Ce qui signifie que vous devez vous déplacer jusqu'à la ligne et de comprendre pourquoi vous êtes obtenir 0 ou acceptable avec retourner null. 0 n'est jamais correct dans ce cas.
    • Tout à fait d'accord avec vous. Cette réponse devrait être interdit de Stackoverflow. C'est le piratage et non réfléchie de la programmation.
    • Quelqu'un peut m'expliquer pourquoi est-ce mauvais? Si je suis à essayer de comprendre un pour cent et le diviseur est égal à zéro, je veux certainement le résultat à zéro pour cent.
    • Je pense que @George et @James/ Wilson fondamentalement mal comprendre la question posée. Il y a certainement des applications d'entreprise où le retour d'un "0" est approprié, même si elle n'est pas techniquement vrai à partir d'un point de vue mathématique.
    • Veuillez donner un exemple, où la valeur 0 comme résultat serait approprié. Vous écrivez "certainement", de sorte que vous certainement un exemple prêt.
    • L'exemple qui m'a conduit à cette page est une compétence de traqueur de calculer le nombre de valeurs de réunion à certains critères ont été choisis parmi toutes les valeurs choisies. Avant que l'utilisateur a entré les données, l'état initial pour le calcul est 0/0 parce que les valeurs n'ont pas été choisis. Alors que de toute évidence, est techniquement une période indéterminée, en disant que le gestionnaire n'est pas particulièrement utile. De retour a la valeur null ou N/A pourrait être votre prochain choix, mais elle n'est pas seulement source de confusion pour comprendre visuellement sur le tableau de bord, l'application que j'utilise n'est pas très flexible. Pourquoi seriez-vous en désaccord?
    • Je suis d'accord, si votre interface utilisateur ne peut pas gérer la valeur NULL ou N/A, et si vous ne pouvez pas modifier l'INTERFACE utilisateur, et bien sûr, vous devez faire quelque chose. Mais c'est un solution et non pas une solution. Un la solution signifierait pour modifier l'INTERFACE utilisateur de ce qu'il peut gérer correctement la division par zéro. Mais l'OP n'a pas rapport au sujet d'une telle situation. Il ne voulait que sa requête ne pas arrêter son exécution sur une division par zéro.
    • Si vous donnez 5 pommes de 0 personnes, combien de pommes ne les gens ont? La réponse est 0, le 0 personnes 0 de la 5 pommes que vous avez. C'est donc la bonne réponse est de 0. Mathématiquement parlant, une division par 0 doit toujours retourner 0. Je n'aime pas les arguments disant qu'il n'est pas possible - c'est juste une règle utilisée par les mathématiques afin de permettre les mathématiques au travail. Est-il possible de donner 5 pommes de 0 personnes? Oui, il est-mais ils cesseraient d'exister dans le contexte.
    • Plus pertinent moyen d'expression de votre scénario (de sorte qu'il implique clairement la division par 0 au lieu de trier les côtés, en train de passer) serait, "5 pommes ont été répartis de manière uniforme entre 0 personnes. Combien de pommes ne chaque personne?" Il n'y a pas intelligible réponse à cette question. Encore plus absurde, essayez d'imaginer le fractionnement d'un objet en 0 pièces. Il est clairement impossible, quelle que soit d'un manque de motivation "pour permettre les mathématiques au travail."
    • Il ya une raison pourquoi x/0 ou même 0/0 n'est pas 0. Un homme d'affaires vend un produit. Le prix change en permanence. Pour voir comment le prix a été en moyenne chaque mois, il calcule: revenu/order_count par mois. Disons qu'il n'a pas de vendre quoi que ce soit sur Mars et nous voulons donc calculer la moyenne pour le premier trimestre. Correct: (20, 30, null) => 50/2 = 25. Mal: (20, 30, 0) => 50/3 = 16,67. (À noter que le calcul de la moyenne dans les deux étapes de cette manière n'est pas vraiment correct. ce n'est pas la moyenne des prix de l'homme d'affaires a obtenu au cours de ce trimestre. C'est plus une supposition de la moyenne des prix de ce produit.)

    InformationsquelleAutor Tobias Domhan
  3. 64

    Ce qui semblait être le meilleur correctif pour ma situation lorsque essayant de répondre à la division par zéro, ce qui arrive dans mes données.

    Supposons que vous voulez calculer le ratio hommes /femmes pour les différents les clubs de l'école, mais vous découvrez que la requête suivante échoue et les enjeux d'une division par zéro erreur lorsqu'il tente de calculer le ratio pour le Seigneur des Anneaux Club, qui n'a pas de femmes: 

    SELECT club_id, males, females, males/females AS ratio
  FROM school_clubs;

    Vous pouvez utiliser la fonction NULLIF pour éviter la division par zéro. NULLIF compare deux expressions et renvoie la valeur null si elles sont égales ou la première expression autrement.

    La réécriture de la requête comme suit: 

    SELECT club_id, males, females, males/NULLIF(females, 0) AS ratio
  FROM school_clubs;

    Un nombre divisé par NULL donne NULL, et aucune erreur n'est générée.

    • Oui en effet, c'est MIEUX que cette autre réponse, qui a reçu tant d'upvotes. Dans votre solution, vous disposez d'au moins une valeur NULL, ce qui indique que vous ne pouvez pas fournir un résultat correct. Mais si vous convertir le résultat de NULL à Zéro, puis vous obtenez tout simplement fausse et trompeuse des résultats.
    • Par ailleurs, si vous souhaitez calculer un ratio hommes/femmes, alors je suggère pour mieux le comparer au total, comme ceci: select males/(males+females), females/(males+females). Cela vous donnera la répartition en pourcentage de mâles et de femelles dans un club, comme 31% des hommes et 69% des femmes.
    InformationsquelleAutor frank
  4. 43

    Vous pouvez également le faire au début de la requête:

    SET ARITHABORT OFF 
SET ANSI_WARNINGS OFF

    Donc, si vous avez quelque chose comme 100/0 il retournera NULL. J'ai seulement fait ce pour les requêtes simples, donc je ne sais pas comment il va affecter plus/plus complexes.

    • Fonctionne pour moi. Dans mon cas, je dois utiliser l'opération de division à la clause where. Je suis sûr qu'il n'y a pas de diviseur de zéro, parce que quand j'ai fait un commentaire OÙ, il n'y a pas de valeurs nulles à des résultats. Mais de toute façon, l'optimiseur de requête, faire une division par zéro, tandis que le filtrage. SET ARITHABORT OFF SET et ANSI_WARNINGS HORS de le faire au travail après 2 jours de combat, avec une division par zéro à la clause where. Thx!
    • Cette "sent" si sale, mais je l'adore! Nécessaire dans une requête d'agrégation et de CAS d'utilisation, la déclaration n'est pas une option, car ensuite, j'ai dû ajouter que la colonne pour le GROUPE EN ce qui a totalement changé les résultats. Faire la requête initiale d'un sous-sélection et ensuite de faire un GROUP BY sur la requête externe modifie également les résultats car il y a des divisions concernées.
    • OK, donc j'aime toujours cette "solution", mais comme beaucoup d'entre vous sans doute senti, j'ai senti qu'il y avait à être un "nettoyeur" façon. Que faire si j'ai oublié de réactiver les mises en garde? Ou quelqu'un cloaned mon code (qui n'arrive jamais, non?) et ne pense pas à les avertissements? De toute façon, vu les autres réponses sur NULLIF(). Je savais à propos de NULLIF() mais ne la réalise pas en divisant par la valeur NULL renvoie la valeur NULL (je pensais que ce serait une erreur). Donc... je suis allé avec les éléments suivants: ISNULL( (SUM(foo) / NULLIF(SOMME(bar),0) ), 0) COMME Avg
    • Je ne connaissais pas cette solution. Je ne suis pas sûr que je l'aime, mais il peut être utile de connaître, un jour. Je vous remercie beaucoup.
    • C'est la solution la plus simple, mais notez que cela va nuire à la performance. À partir de docs.microsoft.com/en-us/sql/t-sql/statements/... : "Réglage de ARITHABORT OFF peut nuire à l'optimisation de la requête conduisant à des problèmes de performances."
    InformationsquelleAutor Taz
  5. 33

    Vous pouvez au moins arrêter la requête à partir de la rupture avec un message d'erreur et retour NULL si il y a une division par zéro:

    SELECT a / NULLIF(b, 0) FROM t

    Cependant, je tiens à JAMAIS convertir cette valeur à Zéro avec coalesce comme il est montré dans cet autre réponse, qui a eu beaucoup de upvotes. Ce qui est totalement faux dans un sens mathématique, et il est même dangereux à mesure que votre demande sera probablement de retour tort et à des résultats trompeurs.

    InformationsquelleAutor SQL Police
  6. 32

    EDIT:
    J'ai beaucoup de downvotes sur cette récemment...j'ai donc pensé que je pourrais juste ajouter une remarque que cette réponse a été écrit avant que la question a subi sa plus récente édition, où retourner null a été mis en évidence comme une option...qui semble très acceptable. Certains de ma réponse s'adressait à des préoccupations comme celle de Edwardo, dans les commentaires, qui semblait préconiser le retour d'un 0. C'est le cas, j'ai été de s'insurger contre.

    RÉPONSE:
    Je pense qu'il y a un problème sous-jacent ici, qui est que la division par 0 n'est pas légal. C'est une indication que quelque chose est fundementally mal. Si vous êtes à la division par zéro, vous essayez de faire quelque chose qui n'a pas de sens mathématiquement, donc pas de réponse numérique, vous pouvez obtenir sera valide. (Utilisation de null dans ce cas, est raisonnable, car il n'est pas une valeur qui sera utilisée plus tard dans des calculs mathématiques).

    Donc Edwardo demande dans les commentaires "que si l'utilisateur met en 0?", et il préconise, il devrait être correct pour obtenir un 0 en retour. Si l'utilisateur met à zéro de la quantité, et vous voulez retourné 0 quand ils le font, alors vous devriez mettre dans le code à l'entreprise des règles de niveau de capture de valeur et de retour 0...pas de certains cas spécial où la division par 0 = 0.

    C'est une différence subtile, mais c'est important...parce que la prochaine fois que quelqu'un appelle votre fonction et s'attend à faire la bonne chose, et il fait quelque chose de funky qui n'est pas mathématiquement correct, mais simplement gère le particulier edge cas il a une bonne chance de mordre quelqu'un plus tard. Vous n'êtes pas vraiment division par 0...vous êtes juste de retour d'une mauvaise réponse à une mauvaise question.

    Imagine que je suis codage quelque chose, et je le visser en place. Je devrais être de la lecture dans un rayonnement de mesure mise à l'échelle de la valeur, mais dans un étrange cas de bord je n'avais pas prévu, j'ai lu dans 0. Puis je déposer ma valeur dans votre fonction...vous me rendre un 0! Hourra, pas de rayonnement! Sauf que c'est vraiment là et c'est juste que j'étais de passage dans une mauvaise valeur...mais je n'ai aucune idée. Je veux de la division de jeter l'erreur, car c'est le drapeau que quelque chose est incorrect.

    • Je suis en désaccord. Vos règles d'entreprise ne devrait jamais faire illégal de mathématiques. Si vous finissez par faire quelque chose comme cela est très probable que votre modèle de données est incorrect. Chaque fois que vous rencontrez une division par 0 vous doivent se demander si les données avaient été NULLE au lieu de 0.
    • Je ne peux pas croire que j'ai été downvoted par quelqu'un qui demande si je n'ai jamais "n'importe quel réel de programmation?" parce que je dis pour le faire bien, plutôt que d'être paresseux. soupir
    • Je suis désolé, je ne voulais pas vous offenser. Mais la question est parfaitement valable dans beaucoup de communes d'applications MÉTIER, et d'y répondre avec un "division par 0 n'est pas légal" ne pas ajouter de la valeur à mon humble avis.
    • quelle est la meilleure façon de s'assurer que nous tenons toujours compte de zéro lors de l'écriture du caractère de barre oblique?
    • c'est le genre de mon point de vue. Il n'est pas valide non plus. Il peut arriver parfois qu'il y est un cas limite, ou une mauvaise saisie de l'utilisateur, ou quelque chose de bizarre comme ça. Pas de question à ce sujet...et elle doit être traitée. Mais mon point de vue (qui, j'imagine, je n'ai pas très bien), c'est qu'il doit être manipulé par la logique métier à l'avant...la capture de ce mauvais/edge/toutes les données, et marquant. Parce que vous n'avez pas vraiment envie de diviser par 0, ce qui est impossible; vous voulez simplement ces cas supplémentaires pour être traités d'une manière élégante. Qui ne devrait pas être fait au niveau SQL, je ne pense pas.
    • henrikstaunpoulsen: je pense que le meilleur moyen est, en général, essayez de le manipuler près de SQL. Si vous êtes de passage dans un 0, alors vous devez être dans un étrange cas de bord, ou ont de mauvaises données, ou quelque chose comme ça...et donc il n'y a pas de point d'aller dans le SQL de la couche de toute façon. Juste le code de la logique de retourner un code d'erreur, ou la valeur null ou ce qu'il devrait faire. Ensuite, vous pouvez laisser votre code SQL aussi propre que possible, et si jamais vous ne voir a /0 erreur vient de là, ce sera une bonne avertissement que vous n'êtes pas attraper un cas que vous devriez être...ce sera une bonne chose, plutôt que d'une mauvaise chose.
    • J'ai frappé ce souvent avec des rapports du prix de vente moyen des transactions. Négatif transactions sont possibles et si le +1 de la vente a un autre prix de vente pour le -1, et elles sont les seules à 2, le psa est mathématiquement undefined. Toutefois, l'entreprise définit le résultat est dans ce cas à être "afficher un blanc pour ASP'. Je ne suis pas sûr si cela tombe sous le coup de vos "règles d'entreprise ne devrait jamais faire illégal de mathématiques" de la règle, mais il semble valide suffit pour moi?
    • La droite. C'est un cas où vous souhaitez les règles de gestion pour gérer un cas particulier d'une manière spéciale...mais il ne devrait pas être le sous-jacentes de math qui renvoie un vide. Il devrait être la règle métier. La accepté de répondre renvoie une valeur null, ce qui est un bon moyen de le gérer. Lancer une exception serait bien aussi. Repérage et de manipulation avant qu'il aille à SQL serait sans doute l'idéal. En fournissant une sorte de fonction que les autres choses pourrait appeler qui a retourné une mathématiquement incorrect de la valeur est pas, le chemin à parcourir, parce que ce cas particulier peut ne pas s'appliquer aux autres appelants.
    • Je dirais que le seul "bon façon de le gérer" est la manière qui vous convient règles d'entreprise, et compte tenu de la question, qui ne comprennent pas forcément de retourner une valeur nulle, comme l'OP ne fournit pas beaucoup de contexte! Bien sûr, je suis d'accord qu'à défaut de comprendre la question au-delà de "il y a un message d'erreur j'ai besoin de se débarrasser de" est dingue 🙂
    • Oui, c'est un bon résumé, je suis d'accord avec. L'origine, la question semblait être libellée comme "que puis-je faire pour que de les masquer cette erreur." Depuis, il a évolué. Retourner une valeur null, la réponse qu'il vient finalement de, ressemble à un raisonnable reponse. (J'ai été fortement préconisant de ne pas retourner un 0, ou un autre numéro).
    • Ne vous déteste cibles en mouvement 🙂 j'ai remarqué que vous êtes connecté à la plupart des sites SE mais pas dba.se: certains de votre base de données de questions serait également sur le sujet là-bas, nous serions heureux de vous compter parmi nous 😉
    • Merci! Enfin quelqu'un qui me dit la vérité ici. Une division par zéro ne devrait jamais retourner zéro. C'est tout simplement faux et conduit à des résultats trompeurs. Comme tu le dis, si vous utilisez le résultat égal à zéro pour la poursuite du traitement dans une autre fonction, alors vous allez propager l'erreur et obtenir plus de mal de fonctions.
    • La règle d'or de la programmation est TOUJOURS LIVRER des RÉSULTATS CORRECTS. Je suis près de 30 ans dans l'entreprise, et je peux vous dire: à Chaque fois que vous êtes un peu bâclée, alors il va revenir à vous comme un boomerang. Et il va vous frapper vraiment mal. Donc, toujours aller le mile supplémentaire et d'essayer d'écrire chaque fonction comme correcte et aussi solide que possible.
    • Je vois votre soupir. Je peux aussi ne pas comprendre comment cette autre réponse, qui offre 0 comme un "résultat" jamais eu 70 upvotes. cela me choque, parce que les programmeurs devraient chercher à écrire des programmes corrects, pas paresseux et bâclée code.
    • Vous êtes totalement correcte lors de la division est appelée. Cependant, il existe certains cas où la division est mal appliqué. Par exemple, % d'écart de x à partir de y. Si x et y sont 0, alors il n'y a pas d'écart de sorte que le résultat correct serait de 0%. Ce résultat est obtenu sans division. Ainsi, un défi à n'importe qui qui pense que 0/0=0 dans leur situation: Expliquer ce que cela signifie et voir si il est plus judicieux de laisser de côté la division. Si vous ne pouvez alors pas défini, NaN ou la valeur NULL est la bonne réponse.
    • Si l'écart entre 0 et 0 est "0%", ce qui est alors l'écart entre 800 et 0? 800 $ chiffre d'affaires en 2016, 0 $ de Ventes en 2015. Qu'est-ce que la déviation ?
    • L'écart est de 800$. Le % d'écart n'est pas défini. Mon exemple, c'est comme quand la simplification des équations algébriques; Si l'on divise par un facteur qui peut être 0, sous certaines conditions, l'équation résultante ne peut pas être appliqué à ces conditions. Cela ne signifie pas qu'il n'y a pas de solution dans ces conditions. Cela ne signifie pas qu'il y en a un, ce qui est le grave erreur que les gens qui sont "pour éviter la division par zéro" sont de décisions.

    InformationsquelleAutor Beska
  7. 26
    SELECT Dividend / ISNULL(NULLIF(Divisor,0), 1) AS Result from table

    En attrapant le zéro avec un nullif(), alors la résultante nulle avec un isnull (), vous pouvez contourner votre erreur de division par zéro.

    • En raison de sa longueur de votre réponse a été recommandé pour la suppression. Notez qu'il est toujours préférable d'ajouter une petite explication de ce que vous suggérez - même si il semble très simple 😉
    InformationsquelleAutor
  8. 10

    Le remplacement de "division par zéro" avec zéro est controversée, mais c'est pas non plus la seule option. Dans certains cas, le remplacement de 1 est (relativement) approprié. Je me retrouve souvent à l'aide de

     ISNULL(Numerator/NULLIF(Divisor,0),1)

    quand je suis à la recherche des changements dans les scores/compte, et que vous voulez par défaut la valeur 1 si je n'ai pas de données. Par exemple

    NewScore = OldScore *  ISNULL(NewSampleScore/NULLIF(OldSampleScore,0),1)

    Plus souvent que pas, en fait, j'ai calculé ce ratio à un autre endroit, pas moins, car il peut jeter un peu de très grands facteurs d'ajustement pour la basse dénominateurs. Dans ce cas, je serais normalement de contrôle pour OldSampleScore est supérieure à un seuil; puis qui s'oppose à zéro. Mais parfois, le "hack" est approprié.

    • Maçon; oui, parfois 1 est une option. Mais comment voulez-vous vous souvenez de la ISNULL partie, lorsque vous tapez une barre oblique inverse?
    • Désolé Henrik - je ne suis pas sûr de comprendre la question.
    InformationsquelleAutor N Mason
  9. 6

    J'ai écrit une fonction a tout à l'arrière de la poignée pour mon procédures stockées:

    print 'Creating safeDivide Stored Proc ...'
go

if exists (select * from dbo.sysobjects where  name = 'safeDivide') drop function safeDivide;
go

create function dbo.safeDivide( @Numerator decimal(38,19), @divisor decimal(39,19))
   returns decimal(38,19)
begin
 -- **************************************************************************
 --  Procedure: safeDivide()
 --     Author: Ron Savage, Central, ex: 1282
 --       Date: 06/22/2004
 --
 --  Description:
 --  This function divides the first argument by the second argument after
 --  checking for NULL or 0 divisors to avoid "divide by zero" errors.
 -- Change History:
 --
 -- Date        Init. Description
 -- 05/14/2009  RS    Updated to handle really freaking big numbers, just in
 --                   case. :-)
 -- 05/14/2009  RS    Updated to handle negative divisors.
 -- **************************************************************************
   declare @p_product    decimal(38,19);

   select @p_product = null;

   if ( @divisor is not null and @divisor <> 0 and @Numerator is not null )
      select @p_product = @Numerator / @divisor;

   return(@p_product)
end
go
    • Salut Ron, solution Sympa, sauf qu'il y a une limite de type de données (4 décimales) et notre @diviseurs peut être négatif. Et comment avez-vous l'application des règles d'utilisation? TIA Henrik Staun Poulsen
    • Je fonçai il assez rapide pour traiter un problème spécifique scénario à l'époque. Développeur de l'app, de sorte que l'application n'est pas si difficile, sauf pour mon mémoire. 🙂
    • En dépit de l'instruction print, ce n'est pas une procédure stockée, il est un scalaire UDF. Cela va vous tuer en MS-SQL si c'est une partie d'une requête.
    • Je suis d'accord avec Mark Sowul l'affirmation que la fonction scalaire va causer de la douleur. C'est un terrible suggestion en T-SQL, ne pas le faire! Les Fonctions scalaires sont les performances des destroyers! Dans la ligne de fonction à valeur de table est le seul bon les fonctions de l'utilisateur dans SQL Server (éventuellement à l'exception des fonctions CLR qui peut bien performer).
    InformationsquelleAutor Ron Savage
  10. 4
    1. Ajouter une contrainte de VÉRIFICATION que les forces de Divisor non-zéro
    2. Ajouter un validateur pour la forme, afin que l'utilisateur ne peut pas entrer les valeurs zéro dans ce domaine.
    • Je commence à aimer la VÉRIFICATION des contraintes de plus en plus.
    InformationsquelleAutor finnw
  11. 4

    Pour la mise à jour de Sql:

    update Table1 set Col1 = Col2 / ISNULL(NULLIF(Col3,0),1)
    • salut Vijay, Oui, cela fonctionnera, mais... je serais attentif à la ISNULL partie, où vous en divisant par la valeur NULL. Je préfère signaler à l'utilisateur que le résultat est inconnu, parce que le diviseur est égal à zéro.
    • Il m'a sauvé dans le complexe sous-requête, Merci.
    InformationsquelleAutor Vijay Bansal
  12. 3

    Il n'y a pas de magie paramètre global au tour de la division par 0 exceptions off". L'opération est à jeter, car le sens mathématique de x/0 est différent de NULL sens, de sorte qu'il ne peut pas retourner la valeur NULL.
    Je suppose que vous êtes en prenant soin de l'évidence et de vos questions ont des conditions qui devrait éliminer les enregistrements avec le diviseur de 0 et de ne jamais évaluer la division. L'habituel "chasse aux sorcières" est que la plupart des développeurs s'attendent à SQL à se comporter comme des langages procéduraux et offre opérateur logique de court-circuit, mais il ne PAS. Je vous recommande de lire cet article: http://www.sqlmag.com/Articles/ArticleID/9148/pg/2/2.html

    • Il y a une telle "Magie paramètre global";SET ARITHABORT OFF.
    InformationsquelleAutor Remus Rusanu
  13. 3

    Ici est une situation où l'on peut diviser par zéro. L'entreprise de la règle, c'est que pour calculer la rotation des stocks, vous prenez le coût des marchandises vendues pour une période, annualiser il. Après vous avez le nombre annualisé, vous divisez par le stock moyen pour la période.

    Je cherche à calculer le nombre de tours d'inventaire qui se produisent dans une période de trois mois. J'ai calculé que j'ai le Coût des Marchandises vendues au cours de la période de trois mois de 1 000$. Le taux annuel des ventes est $4,000 ($1,000/3)*12. Le début de l'inventaire est de 0. Le stock final est de 0. Ma moyenne de l'inventaire est maintenant à 0. J'ai de vente de 4000 $par année, et pas de stock. Cela donne un nombre infini de tours. Cela signifie que tout mon inventaire est en cours de conversion et achetés par les clients.

    C'est une règle d'entreprise de la manière de calculer la rotation des stocks.

    • Oui, vous avez alors un infini nombre de tours. Donc, dans ce cas, si vous avez une division par zéro, alors vous devriez voir quelque chose comme '#INF'.
    • "Le début de l'inventaire est de 0. Le stock final est de 0. Ma moyenne de l'inventaire est maintenant à 0." Votre calcul est une estimation. À un certain moment de l'inventaire est positive ou vous ne pouvez pas le navire et/ou de vendre quoi que ce soit. Si vous n'êtes pas satisfait avec +∞ en conséquence, l'utilisation d'une meilleure estimation de la moyenne de l'inventaire.
    InformationsquelleAutor Jimmy
  14. 2

    Filtrer des données à l'aide d'une clause where de sorte que vous n'obtenez pas de valeurs à 0.

    InformationsquelleAutor nunespascal
  15. 2
    CREATE FUNCTION dbo.Divide(@Numerator Real, @Denominator Real)
RETURNS Real AS
/*
Purpose:      Handle Division by Zero errors
Description:  User Defined Scalar Function
Parameter(s): @Numerator and @Denominator

Test it:

SELECT 'Numerator = 0' Division, dbo.fn_CORP_Divide(0,16) Results
UNION ALL
SELECT 'Denominator = 0', dbo.fn_CORP_Divide(16,0)
UNION ALL
SELECT 'Numerator is NULL', dbo.fn_CORP_Divide(NULL,16)
UNION ALL
SELECT 'Denominator is NULL', dbo.fn_CORP_Divide(16,NULL)
UNION ALL
SELECT 'Numerator & Denominator is NULL', dbo.fn_CORP_Divide(NULL,NULL)
UNION ALL
SELECT 'Numerator & Denominator = 0', dbo.fn_CORP_Divide(0,0)
UNION ALL
SELECT '16 /4', dbo.fn_CORP_Divide(16,4)
UNION ALL
SELECT '16 /3', dbo.fn_CORP_Divide(16,3)

*/
BEGIN
    RETURN
        CASE WHEN @Denominator = 0 THEN
            NULL
        ELSE
            @Numerator / @Denominator
        END
END
GO
    • Je n'aime pas votre solution, parce que l'utilisation d'un fichier UDF forces de l'exécution de la requête dans un seul thread mode. J'aime votre configuration de test. Je voudrais avoir que dans toutes nos fonctions définies par l'utilisateur.
    • Pour moi cette solution est parfait et élégant
    • oui, Udf de très élégant de code. Mais il ne fonctionne pas bien. C'est "les curseurs sur les somnifères". 🙂 Il est aussi difficile de se souvenir pour écrire dbo.Diviser au lieu d'un simple "/"
    InformationsquelleAutor Gregory Hart
  16. 1

    Parfois, 0 peut ne pas être appropriée, mais parfois 1 ne convient pas non plus. Parfois, un saut de 0 à 100 000 000 décrite comme 1 ou à 100 pour cent changement peut aussi être trompeuse. 100 000 000 d' % pourrait être appropriée dans ce scénario. Cela dépend de ce genre de conclusions que vous avez l'intention de tirer sur la base des pourcentages ou de rapports.

    Par exemple, un très petit-point de vente en mouvement à partir de 2-4 vendus et une très grande point de vente en changeant de 1 000 000 à 2 000 000 d'vendu peut signifier des choses très différentes pour un analyste ou de gestion, mais permettrait à la fois de venir à travers comme 100% ou 1 changement.

    Il pourrait être plus facile d'isoler les valeurs NULL que de parcourir sur une bande de 0% ou de 100% des lignes mélangé avec de légitimes de données. Souvent, un 0 dans le dénominateur peut indiquer une erreur ou valeur manquante, et vous ne voulez pas vous contenter de remplir une valeur arbitraire, juste pour rendre votre dataset look bien rangé.

    CASE
     WHEN [Denominator] = 0
     THEN NULL --or any value or sub case
     ELSE [Numerator]/[Denominator]
END as DivisionProblem
    • Je trouve que le problème est de se rappeler de faire quelque chose quand vous voulez faire une division. Si vous ne vous rappelez-vous l'ajout d'AFFAIRE ou NULLIF, vous bénéficiez d'un cas de support dans x semaines, le lundi matin. Je déteste ça.
    InformationsquelleAutor Joeyslaptop
  17. 0

    Vous pouvez gérer l'erreur de façon appropriée lorsqu'il se propage de retour au programme appelant (ou l'ignorer si c'est ce que vous voulez). En C# les erreurs qui se produisent dans SQL va lever une exception que je puisse les attraper et de gérer dans mon code, tout comme toute autre erreur.

    Je suis d'accord avec Beska dans que vous n'avez pas à masquer l'erreur. Vous ne pouvez pas être en contact avec un réacteur nucléaire, mais de masquage d'erreurs, en général, est une mauvaise programmation de la pratique. C'est l'une des raisons pour lesquelles la plupart des langages de programmation modernes de mettre en œuvre la gestion structurée des exceptions à découpler la valeur de retour avec une erreur /état code. Cela est particulièrement vrai lorsque vous êtes à faire des mathématiques. Le plus gros problème est que vous ne pouvez pas distinguer correctement calculé 0 est renvoyée ou un 0 comme le résultat d'une erreur. Au lieu de cela toute la valeur retournée est la valeur calculée et si quelque chose va mal, une exception est levée. Cela va bien sûr dépendre de la façon dont vous accédez à la base de données et du langage que vous utilisez, mais vous devriez toujours être en mesure d'obtenir un message d'erreur que vous pouvez faire.

    try
{
    Database.ComputePercentage();
}
catch (SqlException e)
{
    // now you can handle the exception or at least log that the exception was thrown if you choose not to handle it
    // Exception Details: System.Data.SqlClient.SqlException: Divide by zero error encountered.
}
    • Je pense que nous sommes tous d'accord que cacher l'erreur avec un 0 n'est pas une solution. Ce que je propose, c'est d'écrire notre code de telle façon que chaque "/" est suivi par un "NULLIF". De cette façon, mon rapport/réacteur nucléaire n'est pas laissé seul, mais fait preuve d'un "NULL" à la place de ce fichus d'erreur Msg 8134. De cause, si j'ai besoin d'un processus différent lorsque le diviseur est égal à 0, Beska et je suis d'accord. Nous avons besoin de code. Il est juste difficile de le faire chaque fois que vous écrivez un "/". "/ NULLIF" n'est pas impossible à faire à chaque fois.
    InformationsquelleAutor Despertar
  18. 0

    Utilisation NULLIF(exp,0), mais de cette manière - NULLIF(ISNULL(exp,0),0)

    NULLIF(exp,0) des pauses si exp est null mais NULLIF(ISNULL(exp,0),0) ne cassera pas

    • Je ne peux pas obtenir NULLIF(exp, 0), si 0 est un Zéro, pas un o. Essayez; DECLARE @i INT SELECT 1 / NULLIF(@i, 0) pour voir si vous pouvez obtenir à la briser.
    InformationsquelleAutor Johnny Kancharla
  19. 0

    C'est la façon dont je l'ai corrigé:

    IIF(ValueA != 0 Total /ValueA, 0)

    Il peut être enveloppé dans une mise à jour:

    ENSEMBLE du Pct = IIF(ValueA != 0 Total /ValueA, 0)

    Ou dans un select:

    SÉLECTIONNEZ IIF(ValueA != 0 Total /ValueA, 0) du Pct from Tablename;

    Pensées?

    • Moi et les autres à trouver que le remplacement de "inconnu" avec zéro est dangereux de les corriger. Je préfère de beaucoup la valeur NULL. Mais le plus difficile est de ne pas oublier d'ajouter iif ou nullif sur toutes les divisions!
    InformationsquelleAutor CorvetteGuru