T-Sql money verhonderdvoudigt kosten in Azure

Seeing anything you like? Google translate does not work out? Drop me a note and I will translate this post.

Met Sql Server 2012 Management Studio is het nu eenvoudig om bacpac-bestanden te maken om zo Sql Server databases te exporteren en te importeren. Dit is dé manier om Sql-Azure databases initieel mee te vullen.

Een bacpac bestaat uit een combinatie van: de scripts om de database aan te maken en json bestanden om de te exporteren data in op te slaan. En deze is in zijn geheel gezipt om de overdracht te verspoedigen. (een bacpac stelt ook eisen aan de meta data overigens, de database moet eerst door een validatie heen.)

Wij gebruiken op ons project bacpac-bestanden om onze lokale database dus naar de cloud te brengen.

Gisteren kreeg ik de melding van onze tester dat de prijzen van artikelen, opgehaald uit Azure, honderd maal zo groot waren vergeleken met een lokale database. Ik kon het inderdaad naspelen en kwam er op een gegeven moment achter dat het gewoon aan de vulling van de database lag. De prijzen waren in de Sql-Azure databasetabel gewoon honderd maal hoger.

Het veld was als money in TSql opgenomen. Dit zal historisch ooit in de database geslopen zijn. Persoonlijk vind ik een decimal voldoende. Mocht ik het type valuta (anders dan euro’s) willen opslaan dan zou ik de valuta isocode daarvan in een andere kolom opnemen. En kan een money veld ook met vier cijfers achter de komma omgaan, iets wat veel banken doen om (zichtbare) afrondingsfouten te voorkomen?

Ik heb toen gekeken naar waar dit aan zou kunnen liggen en ik kwam bij de bacpac uit. We hadden nog de originele versie en deze kan je simpel openen door de extensie met .zip te verlengen. Dan kom je ook bij de json bestanden uit en daar stond het: de prijzen waren als decimaal afgebeeld in de json waarden voor de bedragen maar er zat een komma in!

Nu zijn wij Nederlanders en mijn collega had zijn lokale instellingen op Dutch gezet. Op zijn machine is de bacpac aangemaakt. Zou het daar aan liggen, zou de locale van zijn machine een rol spelen? We hebben dus een testje gedaan.

We maakten een tabel met de volgende velden:

[Id] [bigint] IDENTITY(1,1) NOT NULL,[Name] [nvarchar](50) NULL,

[Age] [int] NULL,

[Decimal] [decimal](5, 3) NULL,

[Float] [float] NULL,

[Money] [money] NULL,

[Numeric] [numeric](10, 5) NULL,

[Datetime] [datetime] NULL,

[Datetimeoffset] [datetimeoffset](7) NULL,

Als je deze exporteert met een Engelse locale krijg je:

{“0″:[1,”test   name”,23,”3.566″,”3.566″,”3.55″,”3.56600″,”2012-12-23T21:45:59.0000000″,”2012-12-23T23:45:31.0000000+01:00″]}

Als je deze exporteert met een Nederlandse locale krijg je:

{“0″:[1,”test   name”,23,”3.566″,”3.566″,”3,55″,”3.56600″,”2012-12-23T21:45:59.0000000″,”2012-12-23T23:45:31.0000000+01:00″]}

Het money veld volgt dus inderdaad de locale. En ja, onze databaseprijzen waren dus ingesteld met dat money veld.

Blijkbaar beschouwt Azure, of de conversie er naar toe, 3,55 euro als 355 euro. De decimale komma gaat op in een ‘formattering’ correctie.

Conclusie: klanten van Microsoft die niet met de Engelse locale werken kunnen beter geen money veld toepassen in Sql-Azure. De decimal is een waardig alternatief tot het moment waarop Microsoft besluit deze ‘feature’ te verhelpen.

Advertenties