[VB] Rij verwijderen uit CSV file

[ShitHappens]

Hallo allemaal,

Ik zit met een heel vervelend probleem. Voor een programma wat ik moet schrijven is het nodig om in een CSV bestand af en toe een rij te "updaten": enkele waarden veranderen.
In de eerste kolom staat een ID (uniek), in de methode is al bekend in welke rij velden opnieuw moeten worden geschreven, aan de hand van dat ID.
Na een half uur Google gebruiken, 3 boeken doorgebladerd en overleggen heb ik nog geen resultaten gevonden.
Inmiddels is het mij bekend dat het een oplossing zou kunnen zijn om de delen die behouden moeten blijven in een ander bestand weg te schrijven en daar dan een nieuwe rij, met de aangepaste waarden, daar aan toe te voegen. Het probleem wat ik heb, is dat het uiteindelijke "output" bestand dezelfde naam moet hebben als de input, omdat andere programma's dit bestand ook gebruiken.

Heeft iemand hier een voorbeeldje of een zetje in de goede richting?

[Mental]

Bestand inlezen in een 3dimensionale array:

Array[Regelnummer][Veldnummer]

Waardes veranderen, en array terugschrijven naar file.
Als je moet gaan programmeren moet je dit toch wel kunnen hoor.

Google bijv. eens op: "read file", "streamreader" en zoek uit hoe arrays werken

[Tukk]

Wat gaat er mis met het volgende?

1. Hernoem orginele file (naar bv. file.csv.bezig)
2. Stuur de output naar file.csv.output
3. Verwijder file.csv.bezig
4. hernoem file.csv.output naar file.csv

Dan heb je ook geen problemen met het feit dat het andere proces tussendoor je orginele file begint uit te lezen.

[ZaZ]

Nog wat anders... Als je een CSV file steeds moet aanpassen ben je met het verkeerde formaat in de weer. Dan moet je een database gebruiken of een binair formaat of iets anders wat daar goed in is.
CSV is om te exporteren en daarna transferen/reconcilen.

[roy-t]

Mental schreef op maandag 03 mei 2010 @ 13:14:
Bestand inlezen in een 3dimensionale array:

Array[Regelnummer][Veldnummer]

je bedoelt 2D

[!null]

Juist, het is het verkeerde formaat om te bewerken. Het is echt een typisch import export uitwissel formaat. Geen database.

[ShitHappens]

Na overleg eindelijk toestemming gekregen om een database te gebruiken. Weten te overtuigen dat CSV niet geschikt is om dit te doen.

Ik ging trouwens ervan uit dat het bestand door andere programma's gebruikt wordt... helaas verkeerd geïnterpreteerd, dit zijn gewone mensen die nog op hun "oude" werkwijze verder wilden werken (alias zelf in het CSV file rommelen), die zullen in dit geval maar leren omgaan met het nieuwe werken

[Mental]

roy-t schreef op maandag 03 mei 2010 @ 16:30:
[...]


je bedoelt 2D

Jup

[Gomez12]

ShitHappens schreef op maandag 03 mei 2010 @ 20:05:
Na overleg eindelijk toestemming gekregen om een database te gebruiken. Weten te overtuigen dat CSV niet geschikt is om dit te doen.

Ik ging trouwens ervan uit dat het bestand door andere programma's gebruikt wordt... helaas verkeerd geïnterpreteerd, dit zijn gewone mensen die nog op hun "oude" werkwijze verder wilden werken (alias zelf in het CSV file rommelen), die zullen in dit geval maar leren omgaan met het nieuwe werken

1 tip, niets jaagt je gebruikers zo in het harnas als ze functionaliteit afpakken zonder goede reden en zonder ze een alternatief aan te bieden.

Ik weet niet wat voor gebruikers je hebt, maar als je mij als gebruiker had dan had je maar beter een export / import csv functionaliteit als eerste kunnen bouwen.

De flexibiliteit voor een beetje power-user die csv geeft ga jij in geen 10 jaar kunnen inbouwen in je dbase. Nieuwe extra functionaliteit is leuk, maar ik zou toch ook graag de bestaande functionaliteit niet verliezen...
Oftewel communiceer goed met je gebruikers en luister naar ze, want "die moeten maar leren omgaan met het nieuwe werken" gaat geen hoge ogen gooien anders.

[T020]

Ik ben het inderdaad eens met Gomez12, je kan klanten beter niet zomaar op iets nieuws laten overstappen omdat jij ergens toevallig geen ervaring mee hebt.
Ik weet niet hoe de database gebruikt gaat worden (is het bijv. een simpel progje dat door 1 persoon wordt gebruikt?) maar een csv bestand is erg makkelijk opgebouwd en kan dus erg makkelijk worden bewerkt, voor simpele doeleinden kan het dus best gechikt zijn. Een csv bestand is bijvoorbeeld ook makkelijk over de mail mee te sturen om ergens anders te kunnen worden gebruikt/bekeken (als het bestand tenminste niet groter dan 10mb is, maar bij zulk intensief gebruik zou ik inderdaad eerder naar een database gaan ).
Je moet jezelf dus afvragen of je klanten het de moeite waard vinden om over te stappen op een database in plaats van hier iets werkends voor te maken.

Om terug te komen op je vraag:

ShitHappens schreef op maandag 03 mei 2010 @ 13:11:
Heeft iemand hier een voorbeeldje of een zetje in de goede richting?

Ik heb eens een simpele Java klasse gemaakt die data uit een csv bestand leest en deze in een

Java:

ArrayList<String[]>

zet. Vervolgens kun je met deze Arraylist doen wat je wilt en hem vervolgens weer opslaan in een (nieuw?) csv bestand. Dit principe is denk ik het makkelijkst.

[ShitHappens]

Gomez12 schreef op dinsdag 04 mei 2010 @ 20:42:
[...]

1 tip, niets jaagt je gebruikers zo in het harnas als ze functionaliteit afpakken zonder goede reden en zonder ze een alternatief aan te bieden.

Ik weet niet wat voor gebruikers je hebt, maar als je mij als gebruiker had dan had je maar beter een export / import csv functionaliteit als eerste kunnen bouwen.

De flexibiliteit voor een beetje power-user die csv geeft ga jij in geen 10 jaar kunnen inbouwen in je dbase. Nieuwe extra functionaliteit is leuk, maar ik zou toch ook graag de bestaande functionaliteit niet verliezen...
Oftewel communiceer goed met je gebruikers en luister naar ze, want "die moeten maar leren omgaan met het nieuwe werken" gaat geen hoge ogen gooien anders.

Alle "oude" functionaliteit blijft behouden, maar dan via een simpel formuliertje die in een DB wordt weggeschreven, in plaats van dat de medewerkers in het CSV file zitten te schrijven. Om een indicatie te geven hoeveel mensen gebruik maken van dit systeem: ongeveer 10 die in de DB (nu nog CSV) schrijven, dan nog een man of 30 die dit uitlezen en er informatie aan toevoegen. Dit wordt dan weer door die andere 10 uitgelezen. Voorheen ging deze communicatie ook grotendeels over de mail (veelal met screenshots van het CSV ), welke nu dus ook in de software gebouwd gaat worden. Het is dus zeker niet zo dat het nu moeilijker/lastiger/ingewikkelder gaat worden, maar het tegendeel: gaat vlugger, kan minder mis gaan en is veel flexibeler.
Juist de aanpassingen waar ik nu aan werk waren wensen van de klant. Zij zijn zeer te spreken over het huidige systeem, maar zagen daar graag extra functionaliteiten in om de processen simpeler te laten verlopen. CSV import/export komt er ook zeker bij, in eerste instantie om van de oude naar de nieuwe situatie te migreren, maar ook tbv back-ups en dergelijke.
Ik hoop dat dit een beetje meer duidelijkheid geeft over het hele verhaal.

[!null]

Huh, CSV inhoud per screenshot oversturen?
En waren die screenshots dan ook nog in BMP formaat? Want het wordt dan echt een wedstrijd hoe lomp en omslachtig je iets kunt doen..

[ShitHappens]

Werd direct gepasted in een mail (via Outlook) dus die zou er best een jpeg van kunnen bakken, geen idee eigenlijk.

En juist daarom ben ik juist nu bezig met het automatiseren van dit geklungel onhandige manier van werken

[Gomez12]

ShitHappens schreef op woensdag 05 mei 2010 @ 11:04:
[...]


Alle "oude" functionaliteit blijft behouden, maar dan via een simpel formuliertje die in een DB wordt weggeschreven, in plaats van dat de medewerkers in het CSV file zitten te schrijven.

Tja in een vorige baan werkte ik ook redelijk veel met csv files.

Simpel voorbeeldje van een paar mogelijkheden wat niet standaard in een DB-formuliertje zit :
- Search & Replace over alles ( als iets in hoofdletters moet / gemuteerd moet worden hoef ik geen veld op te geven, het is simpelweg search over alles )
- Met een beetje text-editor heb je regex / macro functies erbij
- Open het bestand in excel en je kan allerlei formules erbij gebruiken
- Delimiters even ietwat verplaatsen met search / replace zodat 2 velden aan elkaar geplakt worden ( wederom over alles )

Maarja, als mensen screenshots van het bestand versturen dan heb je misschien wat minder power-users ertussen zitten

En directie die opdrachten geeft, tja dat verschilt per directie hoe veel die afweten van het dagelijkse proces. Iets te vaak een high & mighty directie tegengekomen die iets wilde, als het af was dan gingen de gebruikers pas tegen de directie klagen en dan kwam er even een 2e lijst met nieuwe functionele eisen als het 1e af was...

[Davio]

Misschien zou overstappen naar XML een goede keuze geweest zijn, omdat je dan het idee van plain text behoudt, maar wel van goede library functies gebruik kunt maken om de data in te lezen en te behandelen.

Nu je al voor een DB hebt gekozen, lijkt dit wellicht een overbodige post, maar ik wilde het toch even gezegd hebben voor als er anderen met dit probleem worstelen.

[Gomez12]

Davio schreef op woensdag 05 mei 2010 @ 13:03:
Misschien zou overstappen naar XML een goede keuze geweest zijn, omdat je dan het idee van plain text behoudt, maar wel van goede library functies gebruik kunt maken om de data in te lezen en te behandelen.

Nu je al voor een DB hebt gekozen, lijkt dit wellicht een overbodige post, maar ik wilde het toch even gezegd hebben voor als er anderen met dit probleem worstelen.

Serieuze vraag, wat heeft XML hier voor zin?

Imho levert het enkel maar extra grote bestanden op, het wordt onleesbaarder voor de mensen zelf.

Voor csv heb je ook gewoon functies om data in te lezen en te behandelen ( ik schat in dat dit er iets meer zijn )

Het enige voordeel wat ik ken van xml boven csv is dat je extra meta-data erin kwijt kan, maar dit heeft wel redelijk wat nadelen.
Als csv altijd voldaan heeft zie ik niet echt de toegevoegde waarde van XML, volgens mij krijg je er alleen maar de nadelen van mee.

[Davio]

Ik suggereerde XML omdat ik binnen Visual Studio wel eens met de XML library van .NET gewerkt heb en hier zitten redelijk nuttige methodes tussen. Aangezien topicstarter VB gebruikt leek me dit het vermelden waard.

Je kan dan ook LINQ to XML gebruiken om je XMLs te queryen, of XPath / XQuery.

Één van de functionaliteiten die topicstarter wilde is het opzoeken van een rij met een bepaalde ID en dat lijkt met bovenstaande manieren die native in .NET zitten goed te kunnen.

En onleesbaarder voor de mensen vind ik wel kort door de bocht.

Want met CSV heb je gewoon regels onder elkaar waarvan je maar moet weten welk veld op welke positie staat. Met XML staat er gewoon een element omheen.

[Maxxi]

Schijf als je XML gebruikt (wat mij idd ook een oplossing lijkt) dan een simpele export naar platte text.

[!null]

@Davio, het gaat om gebruik in combinatie met andere programma's (ik noem MS Excel bijvoorbeeld). Daar kom je met je XML niet zo ver mee.

Hoe dan ook, je hebt je eigen data(base) en dat maakt weinig uit hoe je dat opslaat. Ik stel voor in een echte DB en geen XML of CSV, maar dat komt wel goed. Als export mogelijkheid bied je dan CSV aan.