Firebird hiba windows/linux között
2015-06-27T08:55:57+02:00
2015-06-29T16:12:16+02:00
2022-08-09T16:35:32+02:00
Vargab
Sziasztok!

Az a gondom, hogy a windows-os Axel-számlázó programot szereném távoli adatbázissal használni, de az adatbázisa linux szerveren futna.

Az Axelhez alapban a Firebird2.5 wines verziót szállítják, ezzel win-en működik is szépen a távoli adatbázis.

Én linuxon akarom tárolni (mert linux szerverek rendelkezésre állnak a GTS-ben!) . Feltettem a ~verzióazonos Firebird2.5-super, illetve a Firebird2.5superclassic változatokat is, de amikor rákapcsolódik a program (a kapcsolat kiépül és él a FB logja szerint) akkor hibaüzenetet kapok: Unknown SQL Data type(0)

Tudtok erre valami okosat?

Szerintem a Firebird el kell fedje az oprendszerek közti különbséget, és szabványos sql réteget adni, ezért nem értem mi okozhatja a problémát. Különbséget alapvetően ezekben látok csupán: 32 bites az Axel-es firebird, 64 bites a linuxos, Linuxon \n, windowson \r\n - de a bináris tárolásban ez tökmindegy.

Googléztam kicsit de nem érek rá napokig turkálni, a fél éjszaka nekem nem hozott eredményt.

Légyszi segítsetek erre kitalálni valamit.

Az Axelpro egyébként demoban tölthető, beüzemelhető hálózatosan ha valaki tud veel foglalkozni kicsit.
Mutasd a teljes hozzászólást!
Hogy vitted át a database filet?
Egyszerű file-copy-val? Mert akkor lehetnek ilyesmi gondok architekturák között.

A szokásos mód (ha architekturák vagy verziók között vált az ember) a GBAK használata.
Mutasd a teljes hozzászólást!

  • Nem vagyok FireBird szaki, sujtásom sincs hozzá, de ha ilyesmi hibajelentést kapok PG alatt, akkor általában elszúrtam az adatbázis migrálását.

    Megnézted, hogy jó-e az adtbázisod a távoli szerveren?
    Mutasd a teljes hozzászólást!
  • Hogy vitted át a database filet?
    Egyszerű file-copy-val? Mert akkor lehetnek ilyesmi gondok architekturák között.

    A szokásos mód (ha architekturák vagy verziók között vált az ember) a GBAK használata.
    Mutasd a teljes hozzászólást!
  • Szia. Feltettem a demót, nem telepít FB-t, lokális adatbázissal dolgozik. Ha linux alól (hálózatból) érnéd el az adatbázist, akkor a setup.ini leírása szerint egy másik verziót (nem demó) kell használnod. Arra gondolok, hogy a kapcsolódásnál lokális adatbázist szeretne program kezelni, erre vonatkozó állítási lehetőség nincs az .ini fájlban.
    pl.: connectionString="DataSource=localhost; Database=C:\Users\Gyula\OneDrive\SharpDevelop Projects\Recept1\Recept1\recept3.fdb; User=SYSDBA; Password=masterkey; Charset = UTF8; ServerType=0"
    Üdv. Gyula
    Mutasd a teljes hozzászólást!
  • Köszi, hogy foglalkoztatok vele!

    Láma voltam azthiszem... mivel windowson gond náékül másolgattam a db filet szanaszét ahova épp kellet, a linuxos cuccra is csak feltoltam scp-vel.

    Azért nem működött, mert nyilván a oprendszerek közti különbségek pl. \r\n... miatt nem volt jó.

    Csináltam egy remote backup->recoveryt a debianon futtatva és onnantól jó lett.

    Megjegyzem ~ 10GB volt az eredeti adatbázis file mérete (röpke 6 óra volt a migrálás mire átjött minden az atomvillanás sbességű neten), a linuxra migrálás után 1.5G-vel lett kisseb az adatbázis file!

    De életre kelt és működik.

    Üröm az örömben, hogy hiába tettem a GTS-be 100/100 netre az adatbázist, maga a program nagy [@&X:(] ...ar mert minden kattintás 5-10 sec -et vár, mire megtörténik a dolog. Mindeközben alig van hálózati forgalom, a 2 CPU 20%, memória 30% kihasználtsággal a szerveren, szal gyakorlatilag működik, de életszerűen használhatatlan vacak. Röpke fejszámolás a tapasztalt lassú működés után, 300 számla napi legenerálása minimum 1 órát elvesz az értékes (napi8) időből azzal, hogy várunk a homokórára... Most lehet visszacsinálni az egészet és meás megoldást keresni:)
    Mutasd a teljes hozzászólást!
  • a linuxra migrálás után 1.5G-vel lett kisseb az adatbázis file!



    Ez természetes, a nem használt lapok felszabadulnak, csak a hasznos adat megy át, azt is a lapok jobb feltöltésével teszi át.
    (A Gbak gyakorlatilag a sémát és az adatrekordokat viszi át és az új gépen ismét, alapról, létrejön és feltöltődik az adatbázis.)

    Üröm az örömben, hogy hiába tettem a GTS-be 100/100 netre az adatbázist, maga a program nagy [@&X:(] ...ar mert minden kattintás 5-10 sec -et vár, mire megtörténik a dolog. Mindeközben alig van hálózati forgalom, a 2 CPU 20%, memória 30% kihasználtsággal a szerveren, szal gyakorlatilag működik, de életszerűen használhatatlan vacak.

    Innen a forgalom elemzés segítene (van néhány alacsonyabb és magasabb szintű tool is erre).
    Ha a program van elbarmolva, akkor "dBase szerűen" használja az adatbázist (szinte mindent behoz a memóriába mert 'egyszerű' select * from tabla parancsokkal operál, ami ugye helyben vagy lokális hálón néhány ezres rekordszámnál bagatell adatforgalom.... a neten már nehezebb ügy.
    Ha a válaszidők nagyok, az is más kérdés vagy ha fetch lassú, ott is más a gond.

    A legegyszerűbb ha elsőre egy adatbázis menedzser utility-vel belenézel.
    Ha ott gyorsan jönnek, mennek az adatok, akkor a programmal van a gond, ha az is lassú, lehet keresni megoldást.
    Mutasd a teljes hozzászólást!
abcd