Problème avec cast

Version imprimable

02/07/2012, 18h31
thevirgin

Problème avec cast
Bonjour tout le monde !

J'essaie d'exécuter la requête suivante :
Code:

1 2 select cast((MONTANT) as decimal(17,2)) from MaTable
Sachant bien que le type de la colonne montant est un float !

une erreur alors s'affiche :
Code:

1 2 3 Serveur : Msg 8115, Niveau 16, État 6, Ligne 1 Dépassement de capacité lors de la conversion de float au type de données numeric.
J'ai essayé de faire un round avant de faire la cast mais ça n a pas marché :?

J'espère que vous pourriez m'aider.

Merci d'avance.
02/07/2012, 21h17
JLCantara

Problème avec CAST?

Bonjour,

Ton SQL Server a certainement un problème car sur le mien, ça fonctionne très bien. D'ailleurs, j'ai fait un copier/coller de ton select...

JLCantara.
02/07/2012, 21h48
JLCantara

Problème avec CAST...

Rebonjour,

les erreurs de type
Msg 8115, Niveau 16, État 6
sont associé à des erreurs de conversion parfois bien bizarre... Est-il possible que Montant est le résultat de calculs et qu'il contient plus de 17 chiffres (ou digits)?

J'ai trouvé plusieurs exemples de plantage tout à fait tordu: parfois, SQL est vraiment capricieux...

Bonne chance,
JLCantara.
04/07/2012, 11h47
thevirgin

Bonjour,

Merci pour tes réponses ;)

Le problème est que la colonne MONTANT contient des valeurs du genre : 49254742.670000002. Ces valeurs viennent d'un problème de convertion de type entre oracle et sql serveur !

D'ailleurs c'est pour ça que j'ai essayé de faire le round, mais j 'ai toujours l'erreur de dépassement !!

La requête que j'ai posté marche pour toutes les lignes sauf celles qui sont du genre : 49254742.670000002.

Est ce que tu as une idée comment je pourrais contourner ce problème ?

Merci pour ton aide :)
04/07/2012, 18h03
SQLpro

Quel est le type de la colonne MONTANT ?

Essayez de respecter la charte de postage au lieu de nous faire perdre du temps !!!

http://www.developpez.net/forums/d96...vement-poster/

A +
04/07/2012, 18h42
thevirgin

Bonjour,

La colonne MONTANT est de type Float.

Je suis désolée de vous avoir fait perdre du temps !!

Merci
05/07/2012, 03h09
elsuket

Bonjour,

Il n'est pas possible de stocker la valeur 49254742.670000002 dans une colonne de type decimal(17,2) : celle-ci ne peut avoir que deux chiffres significatifs après la décimale.

Cette valeur provient-elle de votre base de données Oracle ?
Si tel est le cas, quel est le type Oracle de la colonne correspondante ?

Si cela provient d'un calcul, quel est-il ? :)

@++ ;)
05/07/2012, 10h22
thevirgin

Oui ces données proviennent d'une base de données Oracle ( la colonne est de type number ). Elles sont ensuite ramené à sql serveur ( mais la colonne correspendante est de type float ). Est ce la conversion Number-> float est à l'origine de problème ?

Merci pour votre aide

A+
05/07/2012, 11h03
elsuket

Suivant la documentation, pouvez-vous nous donner la précision et l'échelle de la colonne dans voter base de données Oracle ?

@++ ;)
05/07/2012, 11h44
thevirgin

Pour cette colonne, la précision et l'échelle ne sont pas précisés ! elles ont alors les valeurs par défaut.:?

A+
05/07/2012, 15h00
SQLpro

Encore une fois vous n'avez pas respecté la charte de postage... Je la recopie :

Poster le SQL DDL de la définition de vos objets :

C'est facile avec SQL Server :
Dans Entreprise Manager, clic droit sur la table "Toutes les tâches / Générer un script SQL".
Cela permet aux personnes qui tent de vous répondre :
1) de mieux comprendre votre problème (nom clair des objets)
2) de reproduire votre problématique sur leur machine pour mieux vous aider !

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

1
2
3
4
5
6
7
8
9
10

CREATE TABLE [T_CLIENT] (
[CLI_ID] [int] NOT NULL ,
[TIT_CODE] [char] (8) COLLATE French_CS_AS NULL ,
[CLI_NOM] [char] (32) COLLATE French_CS_AS NOT NULL ,
[CLI_PRENOM] [varchar] (25) COLLATE French_CS_AS NULL ,
[CLI_ENSEIGNE] [varchar] (100) COLLATE French_CS_AS NULL ,
CONSTRAINT [PK_T_CLIENT] PRIMARY KEY CLUSTERED ( [CLI_ID]) ON [PRIMARY] ,
CONSTRAINT [FK_T_CLIENT_L_CLI_TIT_T_TITRE] FOREIGN KEY ([TIT_CODE]) REFERENCES [T_TITRE] ([TIT_CODE])
) ON [PRIMARY]
GO

Cela nous permettra de vérifier de visu le type de données.

A +
05/07/2012, 16h33
thevirgin

Essayer au moins de lire la question avant de juger !!!! la question concernant le type de colonne est dans une table qui se trouve dans une base de données ORACLE et non SQL Serveur !!!! Et vous m'expliquez comment générer un script en SQL Serveur 8O

Et si vous pensez que votre manière obligera les gens à respectez votre fameuse charte, vous avez tort !!!!! alors au lieu de vous concentrez sur ceci, essayer de trouver une manière plus intelligente de le faire !

Alors là j'ai assez perdu mon temps aussi ;)

Merci pour votre aide :)
05/07/2012, 17h18
SQLpro

Désolé mais vous vous expliquez mal :
1) votre requête est-elle faite dans MS SQL Server ?
Dans SSMS ou dans une base SQL Server ?
2) votre requête est-elle faite sur une base Oracle par le biais d'un serveur lieé ?
3) si c'est un import de données d'Oracle vers SQL Server, c'est donc bien dans une table MS SQL Server que vous faites cette requête ?

Si tel est le cas, donnez la définition DDL de cette table.

En étant pas clair et en ne respectant pas la charte de postage vous faites perdre du temps !

A +

Ma requête est dans une base Sql Server.

La structure de la table :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
 
CREATE TABLE [dbo].[ARTICLE_FAIT] (
	[ID] [float] NULL ,
	[DATE_DEFAUT_PAIEMENT] [datetime] NULL ,
	[DATE_CREATION] [datetime] NULL ,
	[ANNEE_BUDGETAIRE] [decimal](18, 0) NULL ,
	[DATE_DEBUT_PERIODE] [datetime] NULL ,
	[DATE_FIN_PERIODE] [datetime] NULL ,
	[DATE_DEPOT_VERS] [datetime] NULL ,
	[DATE_EXIGIBILTE] [datetime] NULL ,
	[ANNEE_IMPOSITION] [decimal](18, 0) NULL ,
	[Effectif] [int] NULL ,
	[MONTANT_AUTRES] [decimal](38, 2) NULL ,
	[MONTANT_DROITS_DUS_PRINCIPAL] [decimal](38, 2) NULL ,
	[PRINCIPAL_VERSE] [decimal](38, 2) NULL ,
	[PRINCIPAL_CALCULE] [decimal](38, 2) NULL ,
	[MONTANT_TOTAL_DROITS_DUS] [decimal](38, 2) NULL  
)

Ma table contient déjà les données.

quand je fais :

Code:

1
2
3
4
5
 
select 
cast(ROUND ( MONTANT_DROITS_DUS_PRINCIPAL , 2 )  as decimal(17,2)) MONTANT_DROITS_DUS_PRINCIPAL, 
cast(ROUND ( MONTANT_TOTAL_DROITS_DUS , 2 )  as decimal(17,2)) MONTANT_TOTAL_DROITS_DUS
from ARTICLE_FAIT

une erreur survient :

Code:

1
2
3
4
5
 
(1739 ligne(s) affectée(s))
 
Serveur : Msg 8115, Niveau 16, État 6, Ligne 1
Dépassement de capacité lors de la conversion de float au type de données numeric.

Mais quand je fais :

Code:

1
2
3
4
5
 
select 
cast(ROUND ( MONTANT_DROITS_DUS_PRINCIPAL , 2 )  as decimal(22,2)) MONTANT_DROITS_DUS_PRINCIPAL, 
cast(ROUND ( MONTANT_TOTAL_DROITS_DUS , 2 )  as decimal(22,2)) MONTANT_TOTAL_DROITS_DUS
from ARTICLE_FAIT

ça marche !

Le problème est que je suis obligée d'avoir ce format : decimal(17,2) ( c'est une contrainte de l'outil cognos car je veux utiliser ces montants comme des mesures)

Est ce que c'est possible de rendre ces montants dans ce format ?

Merci pour votre aide

25/07/2012, 16h32
elsuket

Si en augmentant la mantisse à 22 chiffres significatifs, sans changer l'échelle (2) vous n'obtenez plus d'erreur, c'est que vous avez des valeurs qui nécessitent plus de 15 chiffres avant la virgule : 20 avec la mantisse à 22 et l'échelle à 2.

D'un autre côté je vois mal ce que vous pouvez stocker comme valeur qui peut avoir 20 chiffres avant la virgule : des centaines de milliards de milliards ? ...
Même Barclays n'avouerait pas avoir entubé autant ! :mrgreen:

@++ ;)

Il y du monde qui aime stocker le résultat d'une division.
Oracle est bien plus efficace que SQL-Server avec les nombres (et les dates aussi).

Oracle
Code:

1 2 3 select 355/113 from dual; 3.14159292035398230088495575221238938053
SQL-Server
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 select 355/113 3 -- grumph select cast(355 as float) / cast(113 as float) 3.14159292035398 select cast(355 as decimal(38, 37)) / cast(113 as decimal(38, 37)) 3.141592 select cast('3.1415929203539823008849557522123893805' as decimal(38, 37)) 3.1415929203539823008849557522123893805
On fait comment une division avec SQL-Server ?

25/07/2012, 19h01
elsuket

Pour le premier exemple, le fait que diviser un entier par un autre entier retourne un autre entier n'a rien de choquant. C'est d'ailleurs le cas de nombreux langages.

En ce qui concerne le 3e exemple, je ne vois pas comment on peut stocker un entier à trois chiffres significatifs dans un decimal avec un chiffre significatif avant la virgule; d'ailleurs SQL Server non plus et cela produit une erreur :)

Enfin l'exécution du dernier exemple ne pose pas de problèmes sans le CAST().

Une division en SQL Server se fait en respectant les types de données, tout simplement. C'est juste strict :)

@++ ;)
26/07/2012, 15h45
thevirgin
J'ai essayé de détecter les lignes qui me posent problème ( pour voir s ils sont juste des données test ) :
Code:

1 2 3 select * from Article_Fait where (len( MONTANT_DROITS_DUS_PRINCIPAL )> 20 or len (MONTANT_TOTAL_DROITS_DUS)>20)
Le résultat de cette requête est un seule ligne contenant un montant très grand :
Code:

1 2 12 345 678 998 765 400 000
j ai supprimé cette ligne juste pour voir l'impact ! mais le problème de dépassement persiste encore avec les 1700 lignes !!! :?
26/07/2012, 16h56
Waldar
Citation:

Envoyé par elsuket

En ce qui concerne le 3e exemple, je ne vois pas comment on peut stocker un entier à trois chiffres significatifs dans un decimal avec un chiffre significatif avant la virgule; d'ailleurs SQL Server non plus et cela produit une erreur :)

Étrangement il ne m'a pas signalé mon erreur, envoyé le résultat que j'ai copié. Testé sur 2008R2.

Citation:

Envoyé par elsuket

Une division en SQL Server se fait en respectant les types de données, tout simplement. C'est juste strict :)

Justement non :
Code:

1 2 3 SELECT cast(cast(355 AS decimal(38, 35)) / cast(113 AS decimal(38, 35)) as decimal(38, 35)) 3.14159200000000000000000000000000000
La précision de la division reste lamentable.
Code:

1 2 3 4 5 6 7 8 select 35500000000000000000/11300000000000000000 3.141592920353982300 select 3550000000/1130000000 3.14159292035
Donc mes nombres qui ressemblent à des entiers (au sens mathématiques) à partir de dix chiffres significatifs ils sont implicitement convertis en float ?