Vraag over importeren *.csv/*.txt-tabel met één kolom met alleen negatieve waarden

[HeuvelP]

Hallo allen,

Een programma waarmee ik werk, levert managementinformatie in tabelvorm volgens het *.csv-formaat. Deze *.csv heeft zelf kolomkoppen. Als kolomscheidingsteken krijgt hij ; mee.

Eén kolom ("dagen te laat") in deze tabel bevat vrijwel altijd alleen negatieve gehele getallen of 0, omdat de afhandeling van bepaalde werkzaamheden vrijwel nooit te laat is, maar meestal ruim op tijd

In een Access-database heb ik een tabel gemaakt waaraan iedere maand de volgende *.csv moet worden toegevoegd. (Access 2013).
In de kolom "Dagen te laat" wil ik dan natuurlijk die negatieve getallen zien. Het gegevenstype van die kolom heb ik op Numeriek gezet.
Nu blijkt dat het importeren mislukt als in deze kolom alleen gehele, negatieve getallen of nul staat.

Om te inventariseren wanneer dit precies optreedt, heb ik wat varianten gesimuleerd met een simpel tabelletje. Daaruit blijkt:

Als ik bij het inlezen van zo'n *.csv door Access een nieuwe tabel laat maken door de wizard, dan zie ik dat het default gegevenstype van dit veld "datum en tijd" is.
Als ik het vervolgens handmatig aanpas naar Numeriek, werkt het wel.

Als ik van te voren de kolomkoppen bij de *.csv weghaal, dan gebeurt er ook iets aparts:
- bij het importeren in de voorbereide tabel pakt hij dan wel het goede gegevenstype.
- als ik de Access-wizard een nieuwe tabel laat maken, vat hij dit veld nog steeds op als "datum en tijd".

Het probleem doet zich ook voor bij txt-bestanden die ik in het kladblok heb gemaakt en bij excel-bestanden die ik in txt opsla (met scheidingsteken TAB).
Het heeft dus ook geen zin om het bestand als *.txt op te slaan.

Verder heb ik gezien dat het probleem zich niet voordoet als in deze kolom minstens één decimaal getal staat. Of minstens één positief geheel getal.

Conclusie: Bij het importeren van een tabel in een tekstformaat ziet excel een kolom met alleen negatieve gehele getallen of nul standaard als "datum en tijd".

Ik moet dus
- ofwel in de oorspronkelijke *.csv eerst de kolomkoppen verwijderen en de tabel dan importeren in een bestaande tabel
- ofwel eerst importeren in een nieuwe tabel en dan handmatig het gegevenstype van dit veld van "datum en tijd" naar "numeriek" zetten (en dan vervolgens naar de uiteindelijke bestaande tabel waar hij in moet)

Wat zou dit kunnen zijn?
En is er een manier in de instellingen om dit te veranderen, zodat de betreffende kolom wel direct herkend wordt als Numeriek?

Misschien heeft iemand daar al eens ervaring mee gehad.

Groeten,

Philip van den Heuvel

 

[OctaFish]

Da's een heel verhaal . Ik twijfel niet aan je bevindingen, maar logisch is het allemaal niet. En dan heb ik het niet alleen over je eigen onlogica:

Eén kolom ("dagen te laat") in deze tabel bevat vrijwel altijd alleen negatieve gehele getallen of 0, omdat de afhandeling van bepaalde werkzaamheden vrijwel nooit te laat is, maar meestal ruim op tijd

Volgens mij doe je nu een dubbele negatieve waarde: Dagen te laat = aantal dagen ná afgesproken datum. Dat is een negatieve waarde, wat jou betreft, want je moet eerder leveren of op tijd. In dat veld zet jij een negatieve waarde. Min op min is volgens mij gewoon plus . Als ik al een kolom [Datum te laat] zou hebben (zou ik niet, want waarom zou je dat doen?) zou ik daar dus een positief getal in zetten. Je zegt immers nooit tegen je klant dat hij -5 dagen te laat is, je zegt: "je bent 5 dagen te laat". Toch?
En hoe weet ik dat hij 5 dagen te laat is? Ik heb een factuurdatum, een betaaltermijn en een betaaldatum. [Factuurdatum] + [Betaaltermijn] = [Uiterste Betaaldatum]. Als [Betaaldatum] > [Uiterste Betaaldatum], dan is de betaling te laat. Simpel, en volledig volgens correct database gebruik (Normalisatieregels). Eigenlijk is wat jij doet dus sowieso al niet aan te bevelen, mits je dus over de benodigde gegevens beschikt. En dat doe je geheid, want hoe weet je andere programma anders dat de betaling te laat is?

Dit is een lichte terzijde, en zou je probleem ook al gelijk oplossen. Maar gesteld dat je toch op je eigen manier verder wilt, dan moet dat uiteraard ook kunnen. Brengt ons bij de tweede 'fout'. Die ligt dan blijkbaar bij het importproces. Eerlijk gezegd: snappen doe ik die niet. Access kan prima op eigen houtje datumvelden detecteren, maar wat Access (en geen enkel Microsoft pakket) pikt is een negatieve datum! Probeer maar in een datumveld een negatief getal in te vullen: je ziet alleen een foutmelding of hekjes (#). Is logisch: een datum kan van alles zijn, maar nooit negatief. Ooit een afspraakje proberen te maken op -6 februari 2016? Knappe jongen als dat lukt! En nu importeer jij dus negatieve getallen, en Access denkt dat dat datums zijn. Wonderlijk. Nog wonderlijker: als je de veldnamen weglaat, gaat het wel goed? Het enige dat ik kan bedenken is dat het min-teken gezien wordt als maand- of dag scheidingsteken. In dat geval zxou je dan een datum te zien krijgen, die nergens op slaat.

De oplossing is eigenlijk heel simpel: zorg voor een correcte importspecificatie. Dat heb je ongetwijfeld nog niet gedaan, gezien je werkwijze. Is simpel: als je de wizard volgt, krijg je vrij snel een venstertje met een knop <Geavanceerd>. Klik daar op, en je krijgt een dialoogvenster waarin je alle te importeren velden ziet met hun respectievelijke veldnamen en (veel belangrijker) hun veldinstellingen. Daar staat het veld [Dagen te laat] dus verkeerd ingesteld. Je kunt hier het veld aanpassen (loop gelijk de rest ook door). Sla vervolgens de specificatie op zodat je hem de volgende keer weer kunt gebruiken.
Vervolg nu de wizard en je zult zien dat je import er gelijk een stuk beter uit ziet.

Maar ik raad je dus aan om alle berekende velden uit de tabel te kieperen, want berekeningen maak je (zo veel mogelijk) in queries. En de uitkomst van die berekeningen sla je dus (ook weer: daar waar van toepassing) nooit op.

 

[HeuvelP]

Hoi Octafish,

Je hebt gelijk, ik ben ook niet blij met die kolom "Dagen te laat".
Even voor jouw beeld: het is een simpel maandelijks rapport met zo'n 3000 records met zo'n vijftien velden. Elk record staat voor een werkzaamheid, met dingen als nummer, werknemer, locatie, soort werk, doorlooptijd, e.d.
Het gaat dan om een werkzaamheid waar de medewerker 5 dagen voor heeft om die te doen, vanaf het moment dat het werk zich aandient. Als medewerkers dat binnen 2 dagen al klaar hebben, dan zegt de managementrapportage dat deze werkzaamheid -3 dagen te laat is gedaan. Hij zegt trouwens ook dat de doorlooptijd 2 dagen is, dus de kolom "Dagen te laat" is niet alleen onhandig, maar inderdaad ook nog dubbelop. Deze rapportage heb ik niet gemaakt, hoor, ik moet er alleen maar mee werken

Mijn taak is om die voorgebakken maandelijkse *.csv te analyseren en daarom wil ik hem zonder al te veel omhaal eerst in Access hebben en dan kan ik ermee aan de slag...

Idealiter wil ik dan de nieuwe *.csv steeds weer toevoegen aan een bestaande tabel. En niet in een nieuwe tabel.
Bij het toevoegen aan de bestaande tabel zie ik wel de knop <geavanceerd> bij de importspecificatie, maar daar kan ik niet het gegevenstype finetunen. Dat kan alleen als je de brongegevens in een nieuwe tabel importeert. Wat daar wel kan, zie ik, is een kolom overslaan. Ik ga eens kijken of ik dat als work-around kan gebruiken. Dan kan ik toch makkelijk verder. Bedankt voor de tip.

Blijft nog wel een beetje in mijn hoofd zeuren wat hier nou gebeurt...... Apart. Toch eens kijken of ik daar verder nog iets van kan vinden... Misschien maak ik ergens gewoon een vage fout.

Groeten,
Philip

 

[OctaFish]

Bij het toevoegen aan de bestaande tabel zie ik wel de knop <geavanceerd> bij de importspecificatie, maar daar kan ik niet het gegevenstype finetunen. Dat kan alleen als je de brongegevens in een nieuwe tabel importeert.

En dat is helemaal correct; een importspecificatie maak je als je gegevens importeert naar een nieuwe tabel. Maar het werken met importspecificaties zou nogal nutteloos zijn als je elke keer als je iets wilt importeren daarvoor een nieuwe specificatie moest aanmaken. Want wat is het nut dan als je dat maar één keer kan gebruiken? Niet, denk ik. Nee, de kracht ligt hem er juist in dat je bij een volgende import de bij de eerste import (die de tabel maakt) de specificatie kunt toepassen op de import!

Nog mooier wordt het natuurlijk als je de hele import automatiseert met een VBA procedure (kan ook met een (br.....) macro) waarin je ook de specificatie gebruikt.
Sowieso importeer ik gegevens never nooit in de uiteindelijke doeltabel maar ik gebruik dus altijd een importtabel zodat ik de geïmporteerde data eerst nog kan controleren en opschonen voordat ik de import toevoeg aan de uiteindelijke doeltabel.

Wat jou situatie betreft: beter te laat toch maar omgekeerd dan de rit tot het onvermijdelijke einde uitzitten en er dan achter komen dat je in de verkeerde plaats bent .

 

[jwaque]

hier een voorbeeldje van een import code voor VBA

Private Sub KnpImport_Click()
'knop importeert file mbv importspecificatie
'importsepecificatie moet tussen "" staan

DoCmd.SetWarnings False
Dim InvoerDatum As String
Dim InvoerFile As String

InvoerDatum = InputBox("geef datumstuk bestandsnaam", DatumStukInvoerFile)

InvoerFile = "\\..\..\filenaam" & InvoerDatum & ".txt"
MsgBox InvoerFile
DoCmd.TransferText acImportDelim, "OImport", "TblImportO", InvoerFile, False
DoCmd.OpenQuery "QryOImportToevoeg", acViewNormal, acReadOnly
DoCmd.DeleteObject acTable, "TblImportO"
DoCmd.SetWarnings True

Refresh
End Sub

 

[HeuvelP]

Hallo OctaFish, jwaque,

Bedankt voor de input. Hier kan ik goed verder mee.

Gr.,
Philip