een .csv file uitspugen ;)

[JeroenMioch]

Ik heb een quey gemaakt die een excel file output.
Die excel file stuurde ik normaal gesproken naar de ICT afdeling welke er een bruikbare .csv van maakte.
Echter we gaan nu kijken of mijn applicatie direct de .csv file uit kan spugen.

Dit is voor mij nieuwe materie.
Ik heb inmiddels de wizard gevonden maar ik denk dat ik het handmatig moet programmeren.
Sommige gegevens heb ik wel nodig, sommige niet. Dit worden dan komma's.

Voor ik met moeilijke vragen kom wil ik eigenlijk eerst weten hoe ik het moet aanpakken.
Wanneer voeg ik de komma's toe ? Tijdens de query ? of kan ik dit ook doen in de output (excel) file ?
Ik kan natuurlijk ook een tabel maken dmv de query, dan de komma's in de fields zetten en dan pas exporteren.

Kortom, ik hoor de klok klinken, maar weet niet waat de klepel hangt.

Kan iemand me adviseren wat de beste (lees makkelijkste) manier is ?

Met vriendelijke groeten.

Jeroen

 

[OctaFish]

Ik snap niet precies wat je bedoelt met 'komma's toevoegen'. Een (tekst)output bestand scheidt alle te exporteren velden door een scheidingsteken, meestal een komma of een puntkomma. Dat stel je in als je met de wizard de Exportspecificatie maakt. Als je 20 velden exporteert, krijg je dus maximaal 20 waarden, die zijn gescheiden door de komma (laten we het simpel houden). Is een veld leeg, dan staat er niks in de tekst, en krijg je dus niks tussen de komma's. Ergo: als je een record exporteert waar maar in 3 velden iets staat, dan krijg je een hele string van opeenvolgende komma's. Maar nooit meer of minder dan 19 stuks, om dus die 20 velden uit elkaar te houden. Je hoeft dus nooit zelf komma's toe te voegen. Maak eerst maar eens een gewone export, en kijk hoe die er uit ziet. Kon je wel eens meevallen!

 

[JeroenMioch]

Klopt helemaal wat je zegt. Echter de .CSV is een door een andere applicatie bepaald format qua gegevens.
Die gegevens hebben we niet allemaal nodig en zijn dus leeg.
Er zijn tieltallen criteria die opgenomen KUNNEN worden. Alleen doen we dat niet en dus heb ik in de output tussen bepaalde waardes die ik wél nodig heb comma's nodig.

Dan krijg je zoiets als :

 ,,Jeroen,Mioch,,,,,Kenteken,,,Personeelsnummer,,

In bovenstaand voorbeeld zijn de eerste twee comma's mijn title (mr, dr, drs, etc) en aanhef (Dhr, Mw.) maar die gebruiken we niet en dus staan er geen gegevens tussen.

Ik heb inmiddels ook zitten klooien en heb bedacht dat ik een tabel maak met alle comma's en velden die ik wel gebruik er alvast in.
Vervolgens was ik van plan met een SQL de tabel te vullen met gegevens. Is overigens ook nog niet zo gemakkelijk want ook de invoer van de gegevens die ik wél nodig heb moet aan aan een bepaald format voldoet, Om een voorbeeld te noemen moet ik van het veld kenteken, deze eerst de middenstreepjes weghalen. En van een datumveld moet ik ineens dd/mm/yyyy hebben terwijl mijn applicatie waar de brongegevens in staan kenteken met streepjes heeft en datum als volgt dd-mm-yyyy
Dus dat word ook nog ff puzzelen hoe ik dat tijdens de SQL verander.

Als ik het voor elkaar krijg allemaal moet ik daarna de tabel exporteren als .csv

Gaat het lukken zo denk je ?

 

[OctaFish]

Ik zou eerst eens kijken hoe de input aan de kant van de andere applicatie is; doorgaans kun je bij het importeren van een csv bestand aangeven hoe de gegevens moeten worden ingelezen. Zo kun je een import hebben die gebruik maakt van Veldnamen om gegevens te koppelen (ook in je importkant worden de gegevens in records en velden gezet), of je kunt een import aan moeten leveren zonder veldnamen, waarbij op positie wordt gekeken. Zo te zien maak je gebruik van de laatste variant. Maar als je de mogelijkheid hebt om op basis van veldnamen te importeren, heb je die extra komma's niet nodig.
Even uitgaande van jouw verhaal, dat je dus velden op de juiste positie moet zetten, is de oplossing (bedroevend) simpel: kwestie van een query maken, en daar extra lege velden in zetten! dus iets als:

SELECT "" AS 1, "" AS 2, Voornaam, Achternaam, "" AS 3, "" AS 4, IIf([Kenteken] Is Null,"",Replace([Kenteken],"-","",1)) AS Expr1 FROM Projects;

etc. Vergeet dus die extra tabel, die heb je niet nodig. De datum zou je niet hoeven te converteren, want een beetje pakket importeert dat naar zijn eigen format.

 

[JeroenMioch]

Dat ziet er inderdaad een stuk makkelijker uit Michel.
Ik ga er even mee aan de slag en dan laat ik je weten hoe het afloopt.

Alvast hartelijk dank voor de input.

Groeten,

Jeroen

 

[JeroenMioch]

Hoi Michel,

Ik heb het net even geprobeerd en tot nu toe ziet het er perfect uit.
Wat die datum betreft ben ik niet zeker. En die ICT-er die is er niet vandaag. Het liefst lever ik het gewoon aan zoals het voorbeeld wat ik heb gekregen.
Ik moest nog even een WHERE conditie toevoegen, maar dat was zo gepiept.
Het ziet er naar uit dat het klusje inderdaad vrij eenvoudig is, wel dankzij jou hulp natuurlijk.

Groeten en goed Weekend,

Jeroen

 

[OctaFish]

In een export csv bestand zitten geen bestandseigenschappen, alles wordt als tekst beschouwd. Het is aan het import programma om dan te bepalen welk format een bepaald veld heeft. Vandaar mijn opvatting dat het voor het datumveld niet uit zou mogen maken hoe de datum is opgemaakt. Maar als je de datum toch wil converteren, kun je hem met CStr omzetten naar een tekstveld. In dat geval kun je met FORMAT de datumopmaak meegeven die je nodig hebt: het resultaat wordt dan door CSTR omgezet naar tekst, en niet meer aangepast door Access.

 

[JeroenMioch]

Ik heb net hetzelfde gedaan met de voorloop nullen, die weg moesten.

Exp: Val([Pnummer])

Beetje hetzelfde proncipe, al moet ik ff zoeken naar de juiste syntaxis maar dat gaat wel lukken denk ik.
Goed idee die query van je, ben er heel blij mee.
Ik ga aan de slag met die CStr, ik laat wel ff weten hoe het afloopt.

Thanks again !