SQL/C#: Automatisch data type bepalen van kolom

[mootjuhh]

Hallo,

Momenteel ben ik bezig met het maken van een programma om data te importeren in een database. Nu is het geval dat ik uit de source geen andere indicatie van de/het datatype heb (behalve door zelf naar de data te kijken).

Nu heb ik een lege tabel aan gemaakt op basis van het txt bestand met de juiste kolomnamen, maar nu is alles een varchar. Ik zou nu graag willen dat bijv. de eerste 100 regels worden gebruikt om te bepalen dat een datum een datum is en ook zo moet worden opgeslagen.

Weet iemand of dat mogelijk is?

Alvast bedankt.

[supreme tweaker]

Natuurlijk is dat mogelijk. We zullen wel wat meer moeten weten. Op welke manier ben je de data aan het importeren?

[mootjuhh]

Ik heb een tekst bestand met daarin op de eerste rij de kolomnamen gescheiden door een |
Op de tweede en volgende rijen staat vervolgens ook de data gescheiden met en |

Momenteel gebruik ik VS2010 met de SSIS omgeving. Daarin kan ik een groot deel opvangen met C# en verder met standaard functies.

Eerst lees ik de eerste regel van de bestanden om de tabellen te kunnen maken. Daarna wil ik de data importeren. Tot hier gaat het in de meeste gevallen goed. Een aantal errors komen wel naar boven, maar dat zou ook aan de data kunnen liggen. Alles is nu een varchar

[markvt]

Er zijn functies om een kolom te checken of het een bepaald type is
isdate MSDN: ISDATE (Transact-SQL)
isnumeric MSDN: ISNUMERIC (Transact-SQL)

Of met regex checken of de kolom voldoet aan een bepaald formaat?

[Moi_in_actie]

Ik heb ooit eenzelfde iets gedaan waarbij data in een CSV bestand werd aangeleverd, ook alleen met de column headers maar zonder datatypes. Mijn aanpak was destijds dat ik een kleine functie had geschreven waarmee ik in een vaste volgende een soort van parse probeerde naar een bepaald datatype (is het een boolean/bit, integer, datetime, string/nvarchar etc). Ik weet even niet meer exact in welke volgorde ik de checks deed, string/nvarchar was meen ik de laatst mogelijke optie die overbleef.

Dit geintje deed ik initieel voor de eerste 10 records het bestand, aangezien er b.v. na de controle van regel 1 uit kon komen dat kolom 5 een bit (0 of 1) is, terwijl er in regel 6 in diezelfde kolom ineens de waarde 3 stond. Na het doorlopen van die 10 regels (je kunt ook een groter aantal nemen voor meer zekerheid) werd het bestand ingeladen in batches van 1000 of 10000 regels. Mocht hier toch nog een fout ontstaan (in die kolom waarvan je dacht dat het een bit was stond op regel 34521 ineens toch waarde 22), dan kwam er een exception en moest de die hele tabel helaas opnieuw. Dit gebeurde echter vrij weinig. Gebeurt het te vaak, neem dan in de eerste check meer regels op (bijvoorbeeld 100 regels i.p.v. 10).

Ik weet helaas niet meer precies hoe het tooltje in elkaar zat (is alweer een jaar of 5 geleden), maar het was vrij vlot en redelijk accuraat. Redelijk accuraat, in de zin dat wanneer het algoritme er niet uit komt, hij het altijd als nvarchar bestempelde. Vaak terecht, maar heel soms werd er onterecht een datatype niet herkend. Dit b.v. als een datetime in een heel raar format stond. Ook hiervoor heb ik naderhand een manuele override gemaakt, een simpele GUI waarin het tootlje (voordat hij ging importeren) eerst zijn bevindingen van de datatypes op het scherm zetten, waarbij ik het nog manueel kon overriden.

[mootjuhh]

super ik ga eens verder knutselen

[doskabouter]

Ben er wel bewust van dat je dit niet alijd goed krijgt...

Zelfs excel heeft het regelmatig mis (je wil niet weten hoevaak ik dingen opnieuw heb moeten doen omdat excel in zn oneindige wijsheid had besloten om kolommen een bepaald type te geven)

Enkele voorbeelden die me zo te binnenschieten:
- Een kolom waar numerieke ids instonden waar de voorloopnullen essentieel waren
- Numerieke waarden met punten (of komma's, ben het een beetje kwijt) de punten (of komma's dus) die niet volgens de huidige lokale in een int mogen komen gewoon verwijderen