[ASP.NET + C#] string to int met 'leading zeros'

[Griffin]

Ik zit met een convert probleem(pje) waar ik geen antwoord op heb en ook niet kan vinden met google.

Het probleem...:
Ik heb een ASP.NET pagina met daarop een textbox. De waarde hierin moet opgeslagen worden in een database veld met het type 'integer'. Geen probleem dacht ik zo, gewoon int.Parse("string"); Echter het blijkt toch wat complexer te zijn.
Namelijk het feit dat er leading zero's voor kunnen zitten. Het kan dus zo zijn dat een gebruiker "0023" in het veld zet. Na de parse blijft er "23" over en dit wordt in de database gezet. Dit is dus niet de bedoeling.

Nu is mijn vraag hoe ik een exacte kopie, inclusief, de nullen in die string krijg en is het uberhaupt mogelijk.

Ik heb al gezocht met Google naar "convert string to int with leading zero". Het vervelende is echter dat ik allemaal resultaten krijg waar ze een int willen tonen als een string met een x hoeveelheid nummers ervoor. Dat zoek ik dus niet.

Dus toen dacht ik, 'ik kan anders het databaseveld type aanpassen naar varchar'. Helaas dit is geen mogelijkheid, database is niet te wijzigen.
Ook is er geen format die een gebruiker moet invullen. Het kan dus 4 tekens zijn maar kunnen er ook 6 of 9 zijn. Dit is dus aan de gebruiker.

Is dit op te lossen, zo ja hoe dan?

[Woy]

Griffin schreef op donderdag 10 juni 2010 @ 10:49:
Nu is mijn vraag hoe ik een exacte kopie, inclusief, de nullen in die string krijg en is het uberhaupt mogelijk.

Niet parsen, maar in een string opslaan. Leading zeros hebben voor een getal geen betekenis, dus als je die wilt preserveren, zul je het niet als getal op moeten slaan.

[Haan]

Dit is dus niet op te lossen als je de invoer alleen als int op kan slaan. Een int met leading zero's bestaat niet. Als je wel extra columns in de database aan kan maken, zou je de leading zero's wel als string in die column op kunnen slaan

gefeliciteerd btw

[ Voor 4% gewijzigd door Haan op 10-06-2010 11:04 ]

[whoami]

Waarom is het niet de bedoeling om die leading zeroes niet op te slaan ?
Als het gewoon een kwestie van representatie is, dan kan je dat bij het formatten van je pagina toch wel gaan verzorgen ?

Of, hebben die leading zeroes wel degelijk een betekenis ? Dan zal je die gegevens idd als string moeten opslaan.

[Invisible_man]

Als alternatief kan je nog een extra veld in de database opnemen met daarin het aantal decimalen voor de komma dat je wilt hebben. Als daar dan bijvoorbeeld de waarde 4 staat en de daadwerkelijke waarde is 23, weet je dus dat je twee voorloopnullen hebt. Dit kan praktisch zijn als er bijvoorbeeld in de query een vergelijking op de waarde gedaan moet worden (alleen de waardes groter dan 20 bijvoorbeeld) wat op basis van een string lastig is (wellicht helemaal niet mogelijk?), maar als een string geen beperking bied zou ik het gewoon als string opslaan.

whoami schreef op donderdag 10 juni 2010 @ 11:07:
Waarom is het niet de bedoeling om die leading zeroes niet op te slaan ?
Als het gewoon een kwestie van representatie is, dan kan je dat bij het formatten van je pagina toch wel gaan verzorgen ?

Of, hebben die leading zeroes wel degelijk een betekenis ? Dan zal je die gegevens idd als string moeten opslaan.

Bij bijvoorbeeld een telefoonnummer wil je die voorloopnullen bewaren, maar dat is eigenlijk een string (denk aan +31 ervoor en het getal zal ook te groot worden voor een integer).

[ Voor 35% gewijzigd door Invisible_man op 10-06-2010 11:12 ]

[Snake]

Leer lezen...

[ Voor 92% gewijzigd door Snake op 10-06-2010 11:14 ]

[Woy]

Invisible_man schreef op donderdag 10 juni 2010 @ 11:09:
Bij bijvoorbeeld een telefoonnummer wil je die voorloopnullen bewaren, maar dat is eigenlijk een string (denk aan +31 ervoor en het getal zal ook te groot worden voor een integer).

In tegenstelling tot wat de naam telefoonnummer wil doen geloven, is een telefoonnummer ook geen getal, en moet je het dus ook niet zo willen behandelen.

Als de representatie van een getal informatie bevat die invloed heeft op de betekenis, dan is het dus niet puur een getal, en kun je het dus ook beter niet zo behandelen.

[ Voor 16% gewijzigd door Woy op 10-06-2010 11:18 ]

[Snake]

Ultieme hack: zet er een 1 voor en een 1 achter bij het opslaan, en trim die weer bij het weergeven.

* Snake walgt nu wel beetje van zichzelf

[Haan]

Snake schreef op donderdag 10 juni 2010 @ 11:18:
Ultieme hack: zet er een 1 voor en een 1 achter bij het opslaan, en trim die weer bij het weergeven.

* Snake walgt nu wel beetje van zichzelf

Alleen een beetje vervelend als daardoor jouw ingevoerde getal opeens niet meer past in een int

[Reptile209]

Snake schreef op donderdag 10 juni 2010 @ 11:18:
Ultieme hack: zet er een 1spatie voor en een 1spatie achter bij het opslaan, en trim die weer bij het weergeven.

* Snake walgt nu wel beetje van zichzelf

There, I fixed it. Forceer je meteen een string-type en het is makkelijk te Trim()-en .
Nevermind, de database was niet aan te passen. Einde oefening.

[ Voor 8% gewijzigd door Reptile209 op 10-06-2010 11:23 ]

[Griffin]

Ik was al bang voor het 'dat kan niet in een int'.
Denk dat ik maar eens even moet gaan overleggen wat belangrijker is. Of dat het veld een INT is of dat ze leading zero's willen. (ze moeten maar een keuze maken)

@Snake:
Die hack is wel heel vies.

[ Voor 6% gewijzigd door Griffin op 10-06-2010 11:34 ]

[Woy]

Griffin schreef op donderdag 10 juni 2010 @ 11:28:
Ik was al bang voor het 'dat kan niet in een int'.
Denk dat ik maar eens even moet gaan overleggen wat belangrijker is. Of dat het veld een INT is of dat ze leading zero's willen.

Het is heel simpel, als er in die leading zero's informatie zit, dan is het eigenlijk geen getal, ook al is het wel uit cijfers opgebouwd.

@Snake:
Die hack is wel heel vies.

Idd

Reptile209 schreef op donderdag 10 juni 2010 @ 11:22:
[...]

There, I fixed it. Forceer je meteen een string-type en het is makkelijk te Trim()-en .
Nevermind, de database was niet aan te passen. Einde oefening.

En al was de database wel aan te passen, dan waren die leading en trailing spaties ook niet nodig, want dan had je gewoon de input als string zonder modificatie aan kunnen passen.

[IJsbeer]

Waarom is de database niet aan te passen? Vanwege bestaande data (dus problemen met de conversie naar nvarchar?), of ligt de reden ergens anders?

[Griffin]

Overleg is geweest.
In mijn ogen was de database niet aan te passen (doe ik liever niet te snel), maar volgens de baas kon dat wel. Maw het wordt nu een varchar. Een hoop gedoe opgelost, en een conversie script voor huidige data hoef ik me geen zorgen over te maken. Dat doet iemand anders.

[ Voor 5% gewijzigd door Griffin op 10-06-2010 11:46 ]