Közben rájöttem, persze az ember mindig a legegyszerűbb megoldásra nem gondol. :)
A Speciális fülön, ha mindent átállítottam szöveg típusra, akkor is önkényesen meghagyta az eredeti mezőbeállítást, és ott újból minden oszlopnak meg kellett adni a mezőtípust ahol kiválasztható, hogy legyen vagy ne elsődleges kulcs. :)
Én - elég beteg módon - nagyon sok mindent PHP-val dolgoztatok fel, az adatokat pedig a MySQL szolgáltatta.
Viszont jobban belegondolva tuti a típus megadásnál lesz Nálad a probléma, hiszen szövegként semmi probléma nem adódhat a "25:16:00"-val, természetesen az "FFFFFF"-fel se. Tehát valami automatikus felismerés még mindig beleköp a levesedbe...
Igazából nem értem, hogy miért teszi ezt, mert mindent úgy átállítok, ahogy írtatok, és azon kívül is kipróbáltam már amit lehetett.
Minden mezőz szövegre állítottam.
Köszönöm, legalább akkor már a stop_times-ra megvan a megoldás, én erre csak tippelni mertem volna. :)
OS X alá a Filemaker nagyon jó, és az tud szövegből importálni, csak kicsit húzós az ára, bár most van valami akció de gondolom csak az U.S.A területére él 250 helyett 150 dollár.
Valami még mindig a típusok deklarásánál száll el, mert a routes tábla 257-301 sorainak utolsó oszlopai FFFFFF, és sluszpoén, hogy csak azoké. Biztos, hogy nem hexa-ként értelmezi mégis? Én nagyon régen haszáltam Access-t, úgyhogy gyakorlatilag nem tudom, mi a pontos menete egy ilyen importnak, de az tisztán látszik, hogy az általad jelzett sorok egyetlen sajátossága az FFFFFF végződés.
A stop_times importálási hibáid meg egészen biztosan a 23:59:59-nél nagyobb időpontok vannak, mert ebből nálam pontosan 54123 darab van, ez pedig az általad jelzett 108246 hiba fele (mert ugye arrival + departure).
Igazából az a baj, hogy random csinál ilyen hibatáblákat.
Az érdekes, hogy tegnap pl. egyszer megcsinálta a routes táblát jól. Aztán mert nem mentettem el, importáltam megint ugyanúgy, mint elötte és csinált egy hibatáblát oda is.
Szóval nem csak a trips hanem szinte mindegyik táblánál képes erre :(
Közben megnéztem, a 157501 rekordból 128703-ban vannak betűk és 28348 a tisztán szám, azért kérdeztem. Csak a mezőtípussal lehet gond, sajnos nincs más ötletem.
Biztos, hogy szövegként importáltad mindegyik mezőt? A shape_id beugratós, mert az első jónéhány rekordban csak számok vannak, és ezért hosszú egészként akarja importálni, emiatt nem tud mit kezdeni a betűkkel. Hány rekord van a hiba-táblában?
Én meg max. 30 percet szívtam azzal, hogy azokat az adatokat az Excel táblába kinyerjem, amire szükségem volt. (Ha azt nem számoljuk, hogy txt splittelőt kerestem, ami a split közben nem próbálja meg megnyitni nagyon a 108 megás txt-t... :D)
Nem tudod, hogy miért csinálhatja, az Access 2010, hogy megváltoztatok mindent amit írt szakadáskapcsolo, és ennek ellenére létrehoz a bekovertált txt-ből készített tábla mellé egy ugyanolyan nevű hiba táblát is.
Pl. a trips táblánás a shape id oszlopot tette oda
Az nem baj, hogy ha pontra állítom amit írtatok, akkor a dátumelválasztó is pont?
Tyű! Ez leírva is borzasztóan hangzik, de elismerésem, hogy végig csináltad! :)
Egyébként, hogy egy kis műhelytitok is elhangozzon, nálam 1 óra 52 percbe tellett egy Intel ULV SU7300-as procinak, hogy optimalizálatlan MySQL táblákból összelapátolja az összes január 23-i megállóhelyi indulást, illetve lineárisan interplolálja őket és beillessze összesen 2880 pillanatképbe.
Ott voltak kisebb komplikációim, de megoldottam. (txt splittelése jópár részbe, külön munkalapokba importáltam be, és utána a számomra lényegtelen részeket töröltem belőle, majd egy munkalapba visszamásoltam a maradék, "lényegi" adatot :D)
Csak arra tudok tippelni, hogy nem elég nagy a mezőméret, szöveg adattípusnál más hibát nem tudok elképzelni. Ha eleve vesszővel tagolva importálod, akkor mezőnként 50 karakter elég neki mindegyik táblához.
Ez az egyik gond az Excellel (eleve Excel 2007-nél korábbival nem is érdemes próbálkozni), másrészt az, hogy az FKERES függvény baromira lelassítja, főleg egy ekkora adatbázisnál. Előnye, hogy néhány funkció ismeretével (Szövegből oszlopok, FKERES függvény, kimutatás - leánykori nevén pivot-tábla) már fogyaszthatóvá lehet tenni az adatbázist, de egy minimális gyakorlattal Access-ben sem bonyolultabb, ráadásul gyorsabb és rugalmasabbak a lekérdezési lehetőségek.
Az lesz a nyerő, de óvatosan ezzel a logikával, mert lehetséges, hogy egy szám (A/B nélkül) kisegységet jelöl, mert nincs belőle nagy. Asszem erre pont a másik három vonalon kell vigyázni, a csepelin a logika látszólag működik. (Bocs, de nekem most nincs időm így utánatúrni, max. este lenne.)
Ja, megvan a logika: Csepelről hajnalban az 1-es és a 3-as kisegységként megy (4 vonat), a reggeli csúcsra összerakják őket 2 nagyegységbe, napközben szétszedik az 1-est és a 4-est, délutánra ismét összerakják őket (a 3-as ekkor már pihen), majd estére szétszedik a 2-est és a 4-est. Az 5-ös és 6-os pedig csak nagyegységként jár.
