mysql windowson és linuxon

Sziasztok.

Windows és linux alól egységesen szeretném használni a mysqlben létrehozott adatbázisokat.
Windows alatt beállítottam, hogy olyan helyen legyen az adatbázis amit a linuxból is látok.
Linuxban is beállítottam a datadir-t, hogy erre a helyre mutasson. Be tudok jelentkezni a
mysql-be terminálban és látom is adatbázisokat meg a táblákat, de ha bármit csinálnék velük 1033 as hibát dob.

Nem értem a hiba okát, miért lenne inkorrekt a fájl.

Segítségeteket előre is köszi.

Hozzászólások

ugyan az a mysql verzio?

1033 nem a Corrupt tABLE?

logba tuti sir meg valamit...
amugy 1033at dobhat csomo esetben, pl inno hasznalatnal nemtud tmpt irni, vagy NULL van az adatfajlokban, de a leggyakoribb, hogy hianyzik vmi a my.cnf-bol (altalaban innora vonatkozo sorok)

Akkor szokott ilyen hibát dobni, ha nincs megfelelő hozzáférése a TMP könyvtárhoz.

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."

Ezt a mysql szervert használtam már elve, és nem állítottam át csak a datadir-t, ezért szerintem el kellene írnie a temp könyvtárat.
mysql query browserban a pontos hibaüzenet:

1033 incorrect information in file:'./.....frm'

windowson mysql 5.1.30 linuxon pedig 5.0.51 es mysql fut

Kíváncsi lettem valamire: A MySQL belső adatábrázolási formátuma nem egy megállapodott valami mint mondjuk egy fájlrendszer abban a formájában ahogyan a lemezen van? Értem ezt úgy hogy a fájlrendszert kezelő kernelmodul - a fejlesztések és javítások miatt - ugyan változik az idők folyamán, de a hozzá tartozó fájlrendszer általában nem. Ugyanez az analógia nem érvényes az adatbázis kezelőre?

Látom, már meg van a hiba oka, de egy kérdés merült fel bennem:
ilyen esetben nem lehet hibaforrás a linux/ms sorvég különbség?

Nálam is párhuzamosan megy a thunderbird lin/win alól, szóval tudom, hogy működik, de gondolnám a fájlkezelést nem ennyire a legfelsőbb rétegben csinálja a szoftver.

Az, hogy az adatot hogyan abrazolja, es az adatfajlban hogyan tarolja, ket kulonallo dolog. Valojaban egy szoveg semmi tobb, mint bajtok egymasutanja, akarmennyire is ertelmes szovegnek tunik, az adatbazis csak bajtok egymasutanjat latja benne - es igy is tarolja le.
Maganal a belso binaris strukturanal azert irrelevans a sorveg, mert a program maga nem epit arra, hogy barhol is sorveget keressen/talaljon. Innentol kezdve annyira mindegy, hogy a platform mit tart a sorveg karakterrol, a programot magat ugyanis _nem erdekli_
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Igen, viszont gondolom az nem kozos a ket proginal. Amugy, altalaban ugy szokas megirni a parsereket, hogy ne jojjon zavarba varatlan \r karakterektol (ugye a windowsos enter az \r\n, a unixos \n, a ketto kozt egy \r a kulonbseg).
Kulonben meg az a sejtes, hogy a platform fgets fuggvenye van olyan rendes, es elintezi ezt az apro formasagot.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Elég sok mindenen átfutottatok amíg nem olvastam a forumut. Ezek a dogok nekem is eszembe jutottak. De én is úgy gondolom, hogy 2 mysqlnek kompatibilisnek kellene lennie. de még nem volt időm kipróbálni, hogy azonos verzióval hogyan viselkednének.

hogy is van, a szamitogep nem a vagyaink, hanem az utasitasaink alapjan mukodik? :)

amugy 5.1 5.0 kozott eleg sok minden valtozott, mintha meg pont a belso tarolasi mod is
ez onnan remlik, hogy van valami convert script ami 5.0-rol migral 5.1-re es mintha szoptunk volna, hogy 5.1-rol 5.0-ra csak dumpbol lehet downgradeelni.

Tyrael

Igen, csak MySQL-nel a minor verziovaltasok jelenthetnek belso formatumvaltast is, es csak a verzioszam 3. komponensenek valtozasa garantal binaris kompatibilitast. Innentol gondold at amit mondtal.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

remelem nem 2 mysql instance-szal akarod irni/olvasni a ugyanazokat a db-ket egy idoben, mert az szinte garantalt adatkorrupciot okoz a mysql cache-elese miatt.
gyakorlatilag feltetelezi, hogy a fajlok csak rajta keresztul valtozhatnak, es nagyon csunyan meg tud lepodni, hogyha valaki a tudta nelkul firkalja a hata mogott (meg addig is hulyeseget valaszolgat cachebol. :))

Tyrael