Halloj, nu börjar mitt tålamod tryta och jag tänkte att någon av er herrar och damer kan vägleda mig.

Jag har en ASP.NET sida där folk matar in värden i decimaltal med både komma och punkter hejvilt.
Dessa sparas sedan i ett DataSet och då med typen Double. Således har jag fått korrigera alla komman till punkter för att inte datasetet ska få spelet.

Problemet är sedan när jag ska spara det till en databas (SQL-server 2005), kolumnens datatyp är float, via en Stored Procedure så skiter den högaktningsfullt i decimalerna, även om jag har ersatt punkterna med komman. Oavsett vilket så är 90,5 = 91 i databasen.

Detta är galet då precisionen med en decimal i det här fallet är ganska viktigt. Så hur sjutton ska jag göra detta?? Blir riktigt konfys och irriterad på att det inte funkar.

Hjälp.. Någon?

//Johannes

Låter lite märkligt att talet skulle avrundas i databasen... Är du säker på att du tillåter decimaler i fältet i databasen? Kan du lägga till värdet 90.5 manuellt i databasen? Avrundningen sker inte vid presentationen istället?

/Johan

Förstår inte problemet. Varför skickar du en textsträng (med komma eller punkt) till databasen om det är ett float-fält.

Konvertera det inmatade värdet till en Double innan du skickar det till databasen.

Visa koden du använder.
Både C# och SPn, så kanske någon kan se det du missar.
F.ö gillar inte SQL Server att tilldela en float kolumn värden med decimaltecken, vill ha punkt.
Och nej den trunkerar/avrundar inte.
Vilket leder mig till att tro att "avrundningen"redan skett när den sparas i databasen.
Om du däremot skulle ha deklarerat kolumnen som t.ex. decimal(2) då får du det beteendet du beskriver.

Följande värden matas in i sp:n

<code>

ssql = "sp_SaveDetails"
Comm = New SqlCommand(ssql, Conn)
Comm.CommandType = CommandType.StoredProcedure
Comm.Parameters.AddWithValue("@CClass", 1)
Comm.Parameters.AddWithValue("@cAR", "90,5")
Comm.Parameters.AddWithValue("@lGKR", "70,5")
Comm.Parameters.AddWithValue("@lZ", "83,5")
Comm.ExecuteNonQuery()

</code>

SP:n ser ut som följer:

<code>
USE CDB
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

CREATE PROCEDURE sp_SaveDetails
@CClass int = NULL,
@cAR float = NULL,
@lGKR float = NULL,
@lZ float = NULL
AS

BEGIN

SET NOCOUNT ON;

INSERT INTO tblDetails (CClass,cAR,lGKR,lZ)
VALUES (@CClass,@cAR,@lGKR,@lZ)

END
</code>

Resultatet i SQL-tabellen om jag kör en SELECT blir:
CCLass = 1
cAR = 91
lGKR = 71
lZ = 84

Och som svar på Martins fråga så måste jag skicka den till datatablen (där datan lagras innan den sparas till databasen) som en Double och då måste jag använda mig av punkt som decimalavgränsare annars får den sinnet och vägrar erkänna värdet som en Double.

//Johannes

Tack för kod.

Drog upp ett C# consoleprojekt klistrade in din kod.
Skapade din tabell.
Skapade din SP (döp INTE dina SPs med prefixet "sp_" så heter SQL Servers egna interna SPs).
Fick byta ut decimalavgränsare till punkt (konverteringserror frånDBn).
Körde frågan.
I tabellen fanns då:
CCLass = 1
cAR = 90,5
lGKR = 70,5
lZ = 83,5

Du pratar om ett datatable och double också någonstans.
Låter som det är där det blir en avrundning.
Läs vad jag skrev förra inlägget om double.

Tack Håkan!

Nu har jag meckat runt och grävt som en galning i koden, och mycket riktigt, den drog alla värden genom en annan klass för validering och där, långt ner i den mörka avgrunden så återfann jag ett

<code>

outp = math.round(inp,0)

</code>

Där satt den.

Tack så mycket för hjälpen, nu kanske jag rent av kan få ner blodtrycket till normal nivå igen.. ;)

M V H
Johannes

Varför inte göra så här:

Comm.Parameters.Add("@CClass", SqlDbType.Int).Value = 1;
Comm.Parameters.Add("@cAR", SqlDbType.Float).Value = 90.5;
Comm.Parameters.Add("@IGKR", SqlDbType.Float).Value = 70.5;
Comm.Parameters.Add("@IZ", SqlDbType.Float).Value = 83.5;

Det ser, i min enkla mening, ganska omständigt ut i jämförelse med det jag har nu.

//Johannes

Bra att det bidrog till att isolera var du skulle felsöka, och att du hittade felet.

Det känns mer felbenäget att hantera tal som strängar. En ganska bra anledning att ta den lite längre varianten. Dessutom är den tydligare

>Det ser, i min enkla mening, ganska omständigt ut i jämförelse med det jag har nu.

Det är nästan alltid "ganska omständigt" att göra rätt om man bara ser till koden.

Den enkla vägen ledde ju till högt blodtryck vilket jag tycker verkar omständigt.