A fájl a táblák importálási specifikációit is tartalmazza, így frissítések esetén egyszerűen újraimportálhatók a táblák. Ezenkívül egy minta-lekérdezést is tettem az adatbázisba, a forgalmi számos mezővel együtt.
A dolog egy-az-egyben a GTFS-ből lett kinyerve, itt-ott belemódosítgattam annyit, hogy pl. a körjárat-szerű útvonallal bíró éjszakaiaknál az amúgy végállomásként meghirdetett, és ott kettébontott meneteket egybeillesztettem (950 Rákospalotai része, 972, 994, 998). Evidensen egy sor egy menet..
Még jó, hogy nem Te vagy az Access motorja, mert működik. :-) Hol látsz benne hibát? Mondjuk ezen a SzövegbenVissza függvényen én is meglepődtem, hogy létezik. (Access 2003 magyar verzió.)
Érdemes mindig egy vadiúj Access adatbázissal indítani, vagy az Eszközök -> Adatbázis-segédeszközök -> Adatbázis tömörítése és helyreállítása funkcióval utólag "gatyába rázni" az adatbázist (ez utóbbit Access 2003-ra írtam, a 2007-esben még nem találtam meg ezt a funkciót). Ilyenkor rákérdez, hogy hova mentse másként, de nyugodtan felülírhatod az eredetit.
Van ugyanis egy olyan sajátossága az Access-nek, hogy ha beleviszel valami új adatot, és utána törlöd / felülírod a régit, ott marad az üres hely. A fenti funkció kinyomja a levegőt az adatbázisból, a HDD töredezettségmentesítéséhez (magyarul defrag :-) ) hasonlóan összevonja az adatokat, néha csodákra képes a fájlméretet illetően.
Érdekes modon az eddig leirtakkal sikerült szuperul, de most ahogy beimportáltam és megvolt az acess 1,4GB-ot írt méretnek, majd lekérdeztem volna és azt irta ki hogy túl nagy az adatbázis.
Valóban úgy tűnik, hogy frissült; ha lesz időm, összedobom az mdb-t. A forgalmi szám megoldható segédtábla nélkül is az alábbi függvénnyel (remélem, a legfrissebb verzióban is működni fog így):
Már csak a a "pihenők/váltások, és a garázsmeneti idők, átszereléseket" kellene egy lekérdezésbe és már akkor lenne 100%, bár így is kikövetkeztethető a PIH és GF, FG....
Na, fog ez menni: négy lekérdezéssel, és úgy fél órányi manuális munkával (excelben tologatás, formázás, stb.) egész pofás indítási jegyzéket lehet összedobni, ami még nagyban hasonlít is az eredetire:
Sőt, némi intuícióval, a pihenők/váltások, és a garázsmeneti idők ismeretében még a beo-keret is megalkotható:
Oké, kezdek megvilágosodni: pl. az A77696RHPCsZ-021 menetrend általános érvényessége (Calendar tábla start_date és end_date mezője) 20120130-20120430, és hétfőtől péntekig. A Calendar_dates tábla viszont ebből kiveszi a - hétköznapra eső - 20120315, 20120405, 20120406 és 20120409 dátumokat (exception_type=2). Mivel a lekérdezésem ezzel nem tudott mit kezdeni, mert feltétel nem volt hozzá, viszont a tábla jelen volt, hát a négy kivétel dátummal - amit nem jelenítettem meg - lehozta négyszer.
Hopp, megvan a "bűnös": a Calendar_dates tábla tartalmazza négyszer "ugyanazt", ezt a táblát kiirtva meggyógyult a lekérdezés, minden csak egyszer jön le.
Azt hiszem, most belemélyedek jobban ennek a táblának az értelmezésébe...
Szerinte tedd be a Calendar táblából a start_date és end_date mezőket, ott lesz a kutya elásva, különböző dátum-intervallumokat fog kihozni. A Calendar_dates táblát meg akár törölheted is a lekérdezésből.
Jó, ez a 20E kiiktatásos menetrendje. A K1 a 83-ason is egyszer jött le nekem. Beírtam én is a 20E-t, hétfőt, dátumot, lejött ugyanez nekem is egyszer. De dátum nélkül az alap, a holnapután érvényes háromszor jön le (ez a A76326AHCCsZ-011 menetrend), a kiiktatott (ez pedig a A76784K1HCMA-0011) egyszer. Megpróbálnád a te feltételrendszerddel az alapmenetrenddel is?
Ilyenkor van olyan lehetőség, hogy a szumma gombbal összesítjük az azonos sorokat. Ha tényleg minden mező egyforma, akkor csak egyszer fog megjelenni.
Ez viszont csak tüneti kezelés, a hiba okának kiderítéséhez be kell tenni minél több mezőt, mert valamelyik (a lekérdezésben meg nem jelenített) mező valószínűleg eltérő értékeket fog kiadni, de ez alapján sajnos nem tudom megmondani, hogy melyik. (Nekem nem hozott ki többféle indulást ezekkel a feltételekkel.)
