Access TEXT data naar DATETIME data

Status
Niet open voor verdere reacties.

StudentDennis

Gebruiker
Lid geworden
13 nov 2013
Berichten
34
Beste mensen,

Ik ben al een aardige tijd bezig een management informatie database te bouwen. Ik heb data van oktober, november en december. Het punt waar ik al het langst mee worstel is dat ik data importeer met het datatype TEXT. Op het moment dat ik in Access het datatype aanpast van TEXT naar DATETIME verandert de opbouw van de datums boven de 13e dag van de maand.

Dus met datatype TEKST ziet de opmaak van de kollom er zo uit in Access:

11/10/2013 23:19:24
12/10/2013 23:19:24
13/10/2013 23:19:24

En omet datatype DATETIME ziet de opmaak van de kollom er als volgt uit in Access:

11/10/2013 11:19:24 PM
12/10/2013 11:19:24 PM
10/13/2013 11:19:24 PM

dus geen 11, 12, 13,
maar 11, 12, october (10e maand)

Dit is opmerkelijk want als ik in de rauwe data kijk (CSV gescheiden door puntkomma's) met Notepad++ (dat ik binnenhaal als http-request van TomTom Webfleet) zie ik een vast notatie: bijvoorbeeld:
;"7-11-2013 12:11:55";

Ik heb al dagen besteed om het werkend te krijgen, maar zonder succes. Ik heb ook geprobeerd het eerst in Excel te importeren (omdat ik las dat die een betere import/export functie heeft).

Ik snap niet hoe ik de data netjes werkbaar krijg.

Ik hoop dus weer een beroep op dit forum te kunnen doen.

Gr Dennis


Kleine toevoeging. In Excel ziet het er als volgt uit met celeigenschappen Datum:

13-11-2013 08:02:18
12/11/13 14:54
12/11/13 14:41
12/11/13 11:29
12/11/13 10:29
12/11/13 9:41
12/11/13 8:09
11/11/13 15:02
11/11/13 14:07
11/11/13 9:47
11/11/13 9:04
11/11/13 8:16
9/11/13 12:42


Ik heb ook aangepaste celeigenschappen geprobeerd met de datumopmaak als in de rauwe data.
 
Laatst bewerkt:
Als je dit verschijnsel opmerkelijk vind, dan ben je snel van slag ;). Het heeft namelijk te maken met een veel voorkomend probleem: het verschil tussen Amerikaanse en Europese datumnotatie. Je geeft zelf al aan dat de opmaak van je csv bestand al niet overeenkomt met de feitenlijke waarden die uit TomTom komen ("7-11-2013 12:11:55" is niet hetzelfde als "7/10/2013 12:11:55"). Dus daar zit ook al een vertaalslag. Een importbestand in Access kun je wel als zodanig goed instellen, als je gebruik maakt van een Importspecificatie. Ik vraag me af of je dat wel gedaan hebt.
 
Beste OctaFish,

Bedankt dat je altijd klaar staat met een snel en intelligent antwoord. Dat is echt super, en dat allemaal vrijwillig, geweldig!

Ik kende Importspecificatie nog niet en heb het geprobeerd.

Wat ik gedaan heb is het volgende:

-http request
-save as.. .csv
-Externe gegevens > Tekstbestand > Geavanceerd:
Radiobutton Gescheiden
Scheidingsteken veld ;
Tekstscheidingsteken "
Taal: English
Codetabel Western European (Windows)
*Datumvolgorde: DMJ
*Datumscheidingsteken: -
Tijdsscheidingsteken: :
Jaar met vier cijfers (aangevinkt)
Voorloopnullen in datums (niet aangevinkt)
Decimaalsymbool: .

De waarden zonder sterretje stonden al zo, met sterretje heb ik zo aangepast

Toen heb ik op OK gedrukt en daarna:
-Met scheidingstekens
-Volgende
-Puntkomma
-Eerste rij bevat veldnamen aangevinkt
-Volgende
-Kolom geselecteerd > gegevenstype Datum/tijd
-Volgende
-Zelf primaire sleutel bepalen: tripid
-Volgende
-Naam: OctaFishTest
-Voltooien

De eerste keer lukte het niet, de tweede keer heb ik het geprobeerd doormiddel van in de exportwizard al aan te geven welk veld datum/tijd moest worden, nu is het wel gelukt de notatie is nu mm/dd/yyyy, maar opzich valt daar wel mee te werken. Heel hartelijk bedankt voor je tijd!

Ik zal je naam en de naam van het forum noemen in mijn dankwoord van mijn scriptie :)
 
Riekt alsof je een werkende oplossing hebt :). Dan kan de vraag op <Opgelost>. Overigens kun je, als de datums nu goed worden ingelezen in de tabel, de notatie van het veld in de tabel naar eigen inzichten aanpassen. De importspecificatie zorgt ervoor dat de gegevens op de juiste manier worden gelezen, en als een datum eenmaal klopt is het in wezen niet meer dan een getal, wat je zelf verder kunt opmaken.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan