De ugye az megvan, hogy kétmillió sor betöltésénél nem kellene böngésző és webszerver legyen a dologban? Itt lenne rögtön az Sql*Loader az ilyen esetekre.
van egy olyan problémám, hogy egy kb. egy-másfél óra hosszú tárolt eljárás, ami APEX lapról indítva hibátlanul lefut kisebb állományok esetén 10-20 perc alatt, ha a legnagyobb (ami 2 millió soros fájlt olvas be) betöltést futtatom, minden hibaüzenet nélkül leáll. Ugyanez a tárolt eljárás, ugyanazzal a paraméterekkel, PL/SQL Developer-ből és SQL Developer-ből indítva simán, hiba nélkül lefut. Mindenhol van hibakezelés, az APEX timeout értékek maximumra, 28800 sec-ra állítva. Soronkénti követés (file sorszám tmp táblába írása) után kiderült, hogy nem mindig pont ugyanott szakad meg...
:(
Mivel nincs hibaüzenet, elképzelésem sincs hogy honnan közelítsem meg a problémát.
Nem tűnik használhatatlannak (már ha valaki elviseli ezt a TOAD-szerű elrendezést), de nem feltétlenül Oracle-ra van kihegyezve. Pl. a PL/SQL színezése elég borzasztó: még a BEGIN és az END sem sikerült egyforma színűre. Gondolom, nyomkövetést sem tud a kódban.
Visszajöttem, nekiállok megpróbálni megtanulni, mi tud az access2007 és hogyan kell hasznláni, mert most használom életemben először, úgyhogy örünék, ha valaki segítene legalább annyira befejezni a programot, hogy legyen egy működő verzió belőle.
Akkor már talán neki tudok látni életre pofozni, de amíg nem működik, nem tudom, hogyan fog kinézni. :-(
Szóval, örülnék minden segítségnek az access fórumon, vagy jobb lenne mail-en, mert az bizosabb.
Úgy értettem, hogy nekem azt tanították, hogy amióta utf van, azóta az összes többit el lehet felejteni, mégis mindenki azokhoz ragaszkodik.
Amúgy nem tudom, mi a különbség utf 8, 16 vagy 32 között, hacsak nem az, hogy a 32-ben van benne az összes betűkészlet, ami számítógépet használó népeknek kell.
K: Az Oracle adatbázisban mezőnként vagy táblánként tudom állítani a karakterkódolást (vö MySQL) ? V: Adatbázisonként, mivel ezt a CREATE DATABASE parancs CHARACTER SET (és NATIONAL CHARACTER SET) záradékával tudod beállítani, és később megváltoztatni nem lehet.
A paraméter amit megadsz setup-kor azt kontrollálja, hogy a db-ben milyen kódolással lesz elmentve a szöveg. A magyar abc-hez az mswin1250 is megfelel, de a default al23utf8 is teljesen jó.
Két további kérdés van.
1. a kliensed amikor egy session-t nyit, mi a session charset. Ha nem adod meg, mindenféle oprendszer regionális beállításokból és hasonlókból defaultolódik. A kliens feltételezi hogy az érkező szöveg session charset-ű, és konvertálja db charsetre. Ugyanígy, ha olvas valamit a db-ből, akkor konvertálja session charsetre.
Mivel a konverzió szimmetrikus, előfordulhat hogy látszólag minnden ok, de valójában nem az.
Példa: session charset utf16, db charset al23utf8. Beírsz windowson egy mswin1250 ő betűt. Alkalmazza rá az utf16->al32utf8 konverziót, az eredményt eltárolja. Visszaolvasod, alkalmazza a reverz konverziót, és visszakapod az ő betűdet. De a db-ben valójában szemét van eltárolva
2. valójában milyen charsetű szöveget küld a programod a db kliensnek. Lásd a fenti példát. Kell tudd, hogy milyen charset a szöveged, és a session charsetet olyanra kell állítanod.
Köszi, de közben feladtam és downgradeltem 11g-re, ott érdekes módon pöccre működik :)
Valahol a telepítés -pontosabban az adatbázislétrehozás- folyamán döglik meg szerintem, amire pl utal az, hogy a dbt lecsapva és az adminalkalmazással próbálkozva sem lehet megoldani, a db létrehozás elszáll nullpointer hibával.
