[php] Import csv *

[Verwijderd]

Reeds heb ik access 2007 in handen en probeer ik een export & import gedeelte voor een site te maken zodat gegevens gesynchronizeerd kunnen worden.

Echter zodra je bij access op export as tekst en je hebt een valuta veld dat geeft hij deze automatish aan als bjivoorbeeld: $2.25 en ons lieftallige phpmyadmin kan die dolar-teken niet verwerken.

Nu vraag ik mij dus eigenlijk af wat de beste aanpak zou zijn met betrekking tot het importerenvan de gegevens. Het export formaat is:

2,"6500001010","maat 1",$2.00
2,"6500001010","maat 2",$2.00
2,"6500001010","maat 4",$2.00

is er iets van een preg_split beschikbaar zodat ik de colomen makkelijk kan scheiden? of moet ik alles gaan zitten loopen voor de syntax?

[GraveR]

Wat is er mis met
http://nl3.php.net/manual/en/function.fgetcsv.php

PHP heeft ingebouwde csv-functionaliteit.

[Verwijderd]

Die dolarteken is mis csv. Access zelf kan niet als csv exporteren ik kan wel een tussenkomst maken
Access -> Excel -> Opslaan als cvs. Als ik hem zo opslaat wederom krijg ik hem in hetzelfde formaat maar dan zonder dolarteken.

Dus vrees ik dat die functie van csv ook niet gaat werken. Het liefst zou ik iets met preg split willen gebruiken. Maar mijn ik zit met een botleneck hoe ik die bijv. "Hallo, dit is een test" over die , heen kan gaan als dat zich in een "" veld bevindt.

Mijn preg is niet zo dramatish goed

[RobIII]

Psst, je zegt consequent cvs maar dat is iets anders dan csv

titlefix: php mport cvs >> [php] Import csv

[ Voor 11% gewijzigd door RobIII op 30-07-2007 12:30 ]

[Verwijderd]

Mijn fout, ik heb even alle teksten ook gefixed ^^

[TeeDee]

Als exporteert vanuit Access kan je toch ook gewoon aangeven dat het scheidingsteken een ; moet zijn en dat de tekst niet tussen quotes komt te staan?

Mocht er een dollar-teken instaan, dan kan je dat toch met een replace methode vervangen met niks?

[Verwijderd]

Nee dat is helaas niet mogelijk gezien 2 redenen.

Nr 1.
Een veld die erbij zit is een omschrijving in een omschrijving zitten diverse tekens. Het kan zomaar mogelijk zijn dat ze ";" of "," er in worden gezet. Als je dan met je find en replace er overheen gaat kom je uit op dit:

Replace: "$" by ""
Input: 2,"6500001010","maat 1 (+$0.35), test, test2",$2.00
Output: 2,"6500001010","maat 1 (+0.35)",$2.00

Nr 2
De bedoeling is dat het exporteer / importeer process naar mensen gaat zonder enige computerervaring behalve de aan/uit knop. Dus 1000-en-1 tussenstappen zoveel mogelijk weglaten.
1000-en-1 is welliswaar zwaar overdreven maar je snapt hem wel.

Nu met die maat omschrijving is dit welliswaar "nog" niet maar het zou er zomaar bij kunnen komen en dan aim ik op een product wat af is niet wat half-afgeschreven is. En op dit zelfde moment zit ik met preg te stoeien ondanks het me best zwaar ligt (zonder geluk helaas).

Tevens wordt dit (toekomstige) importeer-script gebruikt niet alleen voor deze velden. Daarom is het essentieel dat het meerzijdig, dus voor meerdere export-tabellen , gebruikt kan worden.

[Flapp]

Kan je niet gewoon exploden op ,

(Eerst exploden op nieuwe regel natuurlijk)

dat je een array krijgt in de vorm van

$Array[Regelindex][Colomindex]

[ Voor 63% gewijzigd door Flapp op 30-07-2007 14:29 ]

[Verwijderd]

Natuurlijk kan je niet zomaar exploden op ,
Denk eens na dat wanneer jij in de omschrijving schrijft Maat1, maat2
dan scheid hij maat1 en maat2 ook als een kolom.

En als je me niet vertrouwd ik zou zeggen geef het zelf een poging op
print_r(explode(",",'2,"dit is een test, dit is een test",4,5'));

[Flapp]

ah, dan is het zinvol om het met een regular expresion te doen, (wel eerst exploden per losse regel)

[Orion84]

En wat als je nu gewoon je acces tabel zo instelt dat de waardes in die kolom niet meer een valuta type hebben, maar gewoon een getal met twee decimalen, zonder eenheid of iets dergelijks?

[ Voor 5% gewijzigd door Orion84 op 30-07-2007 14:43 ]

[Verwijderd]

Juist ja omdat regular expressions conditioneel kunnen splitten/matchen maar om heel eerlijk te zijn ik heb 15 uur non-stop zitten preg-breien maar ben er nog steeds niet aan uitgekomen.

Momenteel zit ik een functie te schrijven op basis van escape tokens kijken af dat de moeite waard is.
Wis ik maar meer van preg af

[Verwijderd]

Orion84 schreef op maandag 30 juli 2007 @ 14:41:
En wat als je nu gewoon je acces tabel zo instelt dat de waardes in die kolom niet meer een valuta type hebben, maar gewoon een getal met twee decimalen, zonder eenheid of iets dergelijks?

Als je geen type valuata insteld bij access dan verdwijnt alles na de decimaal oftwel 2.25 wordt 2.00. En als je zit als je daarna de waarde alsnog wilt veranderen in 2.25 kan je alleen de 2 veranderen (getal dus voor de decimaal)

[RobIII]

Orion84 schreef op maandag 30 juli 2007 @ 14:41:
En wat als je nu gewoon je acces tabel zo instelt dat de waardes in die kolom niet meer een valuta type hebben, maar gewoon een getal met twee decimalen, zonder eenheid of iets dergelijks?

Dat is imho symptoombestrijding. Je gaat toch niet je onderliggende types veranderen omdat die export niet doet wat je wil?

[TheRookie]

volgens mij kan fgetcsv, zoals al eerder gezegd, voor 99% wat je wil

code:

2,"6500001010","maat 4",$2.00
2,"6500001010","maat 1, maat3",$2.00

output

code:

Array
(
    [1] => Array
        (
            [0] => 2
            [1] => 6500001010
            [2] => maat 4
            [3] => $2.00
        )

    [2] => Array
        (
            [0] => 2
            [1] => 6500001010
            [2] => maat 1, maat3
            [3] => $2.00
        )

)

vervolgens kan je vrij eenvoudig $2.00 omzetten ....

[Orion84]

Verwijderd schreef op maandag 30 juli 2007 @ 14:46:
[...]


Als je geen type valuata insteld bij access dan verdwijnt alles na de decimaal oftwel 2.25 wordt 2.00. En als je zit als je daarna de waarde alsnog wilt veranderen in 2.25 kan je alleen de 2 veranderen (getal dus voor de decimaal)

Mja, ik heb hier geen acces om het uit te proberen, maar ik kan me niet voorstellen dat je een acces kolom niet zo in kan stellen dat hij getalwaardes kan bevatten met twee (bruikbare) cijfers achter de komma, maar zonder dat er persé een valutateken voor moet staan

En anders bestaat er altijd nog de workaround van alles in centen opslaan, zodat je helemaal geen decimalen meer hebt en alles als Integer kan opslaan, maar dat kost dan wel weer wat werk op andere punten natuurlijk.

Je kan wel een hoop moeite steken om die $ tekens uit de tekstfile te slopen die Acces uitpoept, maar volgens mij moet het vrij eenvoudig zijn om de boel zo in te stellen dat die tekens er überhaupt niet inkomen
Dan zit je ook meteen namelijk niet meer met het probleem dat als je over een paar jaar een kolom toevoegt aan je tabel, je weer in je reguliere expressies kan gaan hakken en zagen om de boel aan te passen aan de nieuwe situatie.

RobIII schreef op maandag 30 juli 2007 @ 14:47:
[...]

Dat is imho symptoombestrijding. Je gaat toch niet je onderliggende types veranderen omdat die export niet doet wat je wil?

Het enige nut van zo'n valuta type in acces is dat er zo'n dollar teken voor komt te staan toch Terwijl je dat teken juist niet wilt hebben

Tenzij het heel anders is als in Excel, dan is het enige verschil tussen een Number type met twee decimaal plaatsen en een Currency type de optische formatting met een scheiding bij de duizendtallen en een valutateken
In Excel (in Acces ook?) kan je trouwens ook gewoon het currency type gebruiken, maar zonder valuta symbool.

[ Voor 21% gewijzigd door Orion84 op 30-07-2007 14:56 ]

[Verwijderd]

Oh zo, Ja als je eenmaal de velden hebt opgeborken in kolomen kan je de dolarteken vervangen. Ik ga het eventjes proberen.

Het enige nut van zo'n valuta type in acces is dat er zo'n dollar teken voor komt te staan toch Terwijl je dat teken juist niet wilt hebben

Daar vergis je je berhoorlijk in alles met decimalen heeft een valuta veld nodig. En als met die work-around komt van alles spliten op centen dan breek je de functionaliteit van access.

[ Voor 58% gewijzigd door Verwijderd op 30-07-2007 15:00 ]

[TheRookie]

Verwijderd schreef op maandag 30 juli 2007 @ 14:56:
Oh zo, Ja als je eenmaal de velden hebt opgeborken in kolomen kan je de dolarteken vervangen. Ik ga het eventjes proberen.

Je moet 't idd als 2 aparte problemen zien, eerst de één oplossen en dan voor de ander creatief aan de slag

[...]En als met die work-around komt van alles spliten op centen dan breek je de functionaliteit van access.

Niet splitten op centen, maar je slaat dan geen 2.25 maar 225 op, lijkt me dat je dan nix "breekt"

[Verwijderd]

TheRookie schreef op maandag 30 juli 2007 @ 15:08:
[...]

Je moet 't idd als 2 aparte problemen zien, eerst de één oplossen en dan voor de ander creatief aan de slag


[...]

Niet splitten op centen, maar je slaat dan geen 2.25 maar 225 op, lijkt me dat je dan nix "breekt"

en wat als jij nou eens 225 euro hebt en 2.25 sorry hoor maar om nou in access alles te zitten omreken en omformateren. Dit soort dingen horen juist in een exporteer -> importeer geval, daarom bestaan die processen ook

[TheRookie]

Ik denk dat je 't punt mist voor wat betreft die centen workaround : de suggestie is om alles in centen op te slaan, niet alleen de getallen waar een decimaal in voorkomt
Maargoed, met fgetcsv kom je er denk ik ook wel

[Cipri]

http://pear.php.net/package/File

Beter CSV parser dan dat is er niet, heb er zelf ook nog uren aan test schrijven en fixen ingestopt

[krvabo]

Verwijderd schreef op maandag 30 juli 2007 @ 15:14:
[...]


en wat als jij nou eens 225 euro hebt en 2.25

22500 en 225 .. ?

sorry hoor maar om nou in access alles te zitten omreken en omformateren. Dit soort dingen horen juist in een exporteer -> importeer geval, daarom bestaan die processen ook

Daar heb je dan wel gelijk in, maar als je met een kleine aanpassing iets kunt doen zodat het makkelijker is om te converteren.. mja.

[Verwijderd]

Cipri schreef op maandag 30 juli 2007 @ 15:18:
http://pear.php.net/package/File

Beter CSV parser dan dat is er niet, heb er zelf ook nog uren aan test schrijven en fixen ingestopt

Je snapt geloof ik de issue niet helemaal. Het gaat er niet om dat ik CSV niet krijg geparst het gaat er om dat het formaat dat access uitpoept niet 100% CSV is. Die dolar teken die in het lijstje voorkomt strijd tegen met het CSV formaat.

En p.s. ik met fgetcsv loop ik nu ook naar op een doodeinde aan want nadat hij geparsed is zijn de "" weggehaald. Dus ik kan wel zeggen alles waarvan de eerste teken $ van is dat is een valuta veld doe daar dit en dit mee. Maar wat-als-scenario: Eerst teken van omschrijving is ook een $.

Dit is wederom een bottleneck voor het import procees.

[TheRookie]

Verwijderd schreef op maandag 30 juli 2007 @ 15:29:
[...]
Maar wat-als-scenario: Eerst teken van omschrijving is ook een $.

Dan moet je verder kijken dan je neus lang is
Als je het dollarteken vervangt en is_numeric geeft true dan weet je wat je moet weten; uitzondering is het geval dat de omschrijving alleen een prijs bevat, maar dat lijkt me niet erg voor de hand liggend ...

[Verwijderd]

TheRookie schreef op maandag 30 juli 2007 @ 15:35:
[...]

Dan moet je verder kijken dan je neus lang is
Als je het dollarteken vervangt en is_numeric geeft true dan weet je wat je moet weten; uitzondering is het geval dat de omschrijving alleen een prijs bevat, maar dat lijkt me niet erg voor de hand liggend ...

Het ligt niet voor de hand maar die scenerio's moet wel van worden uitgegaan. Korte samenvatting ik moet de hele getcsv functie herschrijven. Gezien je op een betaalde hosting vrijwel geen eigen dll functie's mag installeren wordt het nog een slome php functie ook netzoals in phpmyadmin

[TheRookie]

Ff nog een heel voor de hand liggende vraag: exporteert access ook de kolomnamen ?

[Cipri]

Verwijderd schreef op maandag 30 juli 2007 @ 15:29:
[...]


Je snapt geloof ik de issue niet helemaal. Het gaat er niet om dat ik CSV niet krijg geparst het gaat er om dat het formaat dat access uitpoept niet 100% CSV is. Die dolar teken die in het lijstje voorkomt strijd tegen met het CSV formaat.

En p.s. ik met fgetcsv loop ik nu ook naar op een doodeinde aan want nadat hij geparsed is zijn de "" weggehaald. Dus ik kan wel zeggen alles waarvan de eerste teken $ van is dat is een valuta veld doe daar dit en dit mee. Maar wat-als-scenario: Eerst teken van omschrijving is ook een $.

Dit is wederom een bottleneck voor het import procees.

Dat is toch niet zo erg, de export is neem ik aan in een bekend formaat, dus je weet het aantal kolommen, en dus ook welke value de prijs moet zijn?

[Verwijderd]

Ja, in het eerste CSV record.


En ik denk dat ik al weet waar je op uitbent namelijk de veldnamen te vergelijken het bijbehorende veldtype en aan de hand daarvan te zeggen deze kolom mag een $ aan het begin bevatten en strip die $.

Iets in die trant maar zoals eerder aangegeven word het script door meerdere tabellen uiteindelijk gebruikt dus kan je niet naar de kolomen kijken want daarmee beperk je mogelijkheid tot tabel-speciafieke import mogelijkheden.

[TheRookie]

goed gedacht
Wie bepaald de kolomnamen ? de eindgebruiker of een systeembeheerder ?

[Verwijderd]

TheRookie schreef op maandag 30 juli 2007 @ 15:57:
goed gedacht
Wie bepaald de kolomnamen ? de eindgebruiker of een systeembeheerder ?

Over algemeen de systeembeheerder. Maar om voor 40 tabellen allemaal apart hun eigen syntax te programeren, nee dank je dan herschrhijf ik liever die csv functie zodat ie later zonder probleem om te zetten is.

In mijn kleine 4 jaar php ervaring is er ding wat ik weliswaar heb geleerd en dat is universeel mogelijk te coderen. Je methode is weliswaar makkelijker voor nu maar voor later een enorme botleneck als ze even besluiten de tabel stuctuur te veranderen.

En als je universeel codeer kan je het nog eens hergebruiken ook
Over dit soort dingen moet je wel even goed nadenken

[Cipri]

Je kan toch een aparte lijst bijhouden met kolomnamen => type conversie? Dan ben je zo klaar.

[ATS]

Sorry hoor, maar die conversie vanuit Access is toch triviaal? Gewoon in plaats van je tabel (of query) een query exporteren waarin je je conversie doet van je currency veld type naar een string of een integer (je gaat toch impoteren in PHP, die kent het verschil niet).

code:

SELECT Veld1, Veld2, CDbl([CurrencyVeld]) AS CurrencyVeld FROM MijnTeExporterenTabel

Als Sjaak van de administratie het moet kunnen, dan moet je zowiezo even een macro of een stukje code maken die je aan een knop of een menu item ofzo hangt, anders gaat het gegarandeerd een keer fout. Het aantal stappen is dan ook niet meer belangrijk.