Miben érdemes Delphi 7 forráskódot migrálni, XE, Lazarus?
2016-02-14T16:46:52+01:00
2016-02-18T17:06:05+01:00
2022-07-22T00:45:10+02:00
  • ,
    Nem vagyok biztos benne, de asszem az Oracle-nek és az SQL szervernek is van ingyenes változata.
    A PostgreSQL egyébként az Oracle-hez hasonlít (főleg a PLpg/SQL a PL/SQL-re). Van windowsra "Next"-es telepítője. Aztán szolgáltatásként fut.
    Gyakorlatban nagyon ritkán telepítettem kliens gépre, inkább linux szerver. Ritka hogy 1 gépen használják.

    A Delphi komponens már neccesebb, ingyenes a ZeosDBO, de azért vannak benne bugok. Fizetősből vannak nagyon jók.
    DB-Aware Components > Direct DB Access > PostgreSQL. Torry's Delphi Pages

    Ennyivel tud többet:
    SQL Feature Comparison

    Ami nekem hiányozna innen:

    window functions, SELECT without FROM, UPDATE with a join,
    Partial index, Writeable CTEs, Multi-row INSERTs,
    BOOLEAN, Dynamic SQL,
    EXCEPT, OVERLAPS, Schemas,
    XML Support, Key/Value storage
    Mutasd a teljes hozzászólást!
  • Akkor már legyen ScaleMM.
    André's Dev Blog: ScaleMM: fast scaling memory manager for Delphi

    "A nyitott alatt a standard user/jelszó hozzáférést értem" ???

    Bármikor megváltoztatható SYSDBA  a jelszó.
    Sőt van olyan trükk hogy felveszel egy SYSDBA ROLE-t, és akkor már mint USER sem használható.
    "At various times people have suggested that removing SYSDBA access to a database could be the solution. The idea behind it is that, when the database is moved to a new server where the SYSDBA password is known, it will not help the person because SYSDBA does not have access anyway. Some have reported limited success in this respect by creating an SQL role name of SYSDBA and making sure it does not have access to the database objects. "
    The Solution
    Mutasd a teljes hozzászólást!
  • A stringeknél az első néhány alkalom után már mindig particionáltam a konkatenálandóakat, a Fast MM-el még nem találkoztam, megnézem.
    Mutasd a teljes hozzászólást!
  • A nyitott alatt a standard user/jelszó hozzáférést értem.

    Az Oracle-t ebben a szegmensben nagyon kevesen fogják megfizetni, az üzemeltetése macerásabb is, mint a next telepítéssel föltett FB-nek.
    A Postgrasql-t nem ismerem, ahogyan az összehasonlítást néztem, többet tud az FB-nél.
    Mennyire macerás föltelepíteni, egyszerű felhasználó is tudja kezelni, újraindítani, leállítani?
    Melyik adatbáziskezelő komponens a legjobb D7 alatt hozzá?
    Mutasd a teljes hozzászólást!
  • "Apró kis hibája, hogy "nyitott" az adatbázis, a forráskódját pedig nem fogjuk átírni."
    ???

    32 bit:
    kb. annyi hogy 2gb memóriával tudsz gazdálkodni, ami még mindig rettentően sok kliens oldalon.
    64 bit: egyáltalán nem futnak gyorsabban a kódok, a memóriaigény meg magasabb, mint 32 bitnél (minden pointer, integer dupla helyet foglal).

    Semmi gond nem lesz a D7-tel, viszont azonnal rakjá' fel FastMM-et (Mellesleg a későbbi Delphi-k is ezt használják).
    A Delphi 7 alap memóriakezelője egy egzotikum:D

    Erre akkor eszméltem fel, amikor régen két egymásba ágyazott ciklussal raktam össze egy táblázatot csv-be.
    Ilyesmikkel kb.: s := s + Sor.Mezo[j].AsString + ';';
    Minden egyes string összeadás egy új memóriaterületen fűzte össze a két részt. Aztán elfogyott a címtartomány: "out of memory", közben kb. 100mb volt a tényleges memóriafoglalás.

    Szóval szerintem win32+D7+FastMM elég kell hogy legyen, ha nem valami egzotikumot fejlesztesz.

    Az adatbázis váltást viszont fontold meg. Ha a projektben kulcs szerepet tölt be az adatbáziskezelés, akkor hosszú távon megéri egy masszívabb dbms-re váltani. Én a PostgreSQL-t javaslom, de Oracle vagy akár MS SQL is jó lehet.
    Ha nincs negyven raklap sql függvényed, akkor válts. (Ha váltasz majd lesz:D)
    Mutasd a teljes hozzászólást!
  • Köszönöm a válaszokat.

    Firebirdre azért esett a választás, mert az előd is ebben írodott, ismerjük, és valóban elég a dllek használata az embedded verzióban.
    Apró kis hibája, hogy "nyitott" az adatbázis, a forráskódját pedig nem fogjuk átírni.

    Letöltöttem a Lazarust, kipróbáltam. Ha kisebb új projectről lenne szó, talán használnám is, de a bonyolult komponensek átportolására esélyt sem látok.

    Mivel az adatbázisát csak a program használja, nem tartok az utf8-tól, ilyen inputok legfeljebb az interfészeken át érkezhetnek, ott pedig vhogyan megoldom a fordítást.

    Döntően egy típusú kódtáblán belül mozgok, ha szükséges, akkor más is szóba jöhet, de nem párhuzamosan.

    Amit láttam az ilyen szoftverek közül, az volt a tapasztalatom, a régi fejlesztéseket reszelgetik, skinezik, gondolom az újra átírások iszonyatos idő és rengeteg hibázási lehetőség is lenne, miközben a régi fenntartása és supportálása, továbbfejleszése is futna.

    Még mindig a D7 mellett szavazok, mert abban gyorsabban tudok kódolni, formokat lehet egyben átemelni.

    Mivel 32 bitet fordít, igaz ugyan, hogy a mai gépek már gigahegyekkel kerülnek ki, de az XE által fordított kódok nem futnak gyorsabban annyira, v kisebb memóriagénnyel, hogy érdemes legyen váltani? Azaz látványos különbség lehet a két környezetben fordított program között futtatás során?
    Mutasd a teljes hozzászólást!
  • hát gondoltam a vállalatirányítási és nyilvántartási rendszer nem beágyazott adatbázist takar:D
    Mutasd a teljes hozzászólást!
  • az adatbázis utf8, de a client_encoding megold mindent (ez mondjuk a db érdeme)
    Mutasd a teljes hozzászólást!
  • Viszont a firebird egy másfél megás dll, amit nem kell külön telepíteni a user gépére (ez persze a beágyazott verzió), míg a postgresql egy elég méretes dolog.
    Mutasd a teljes hozzászólást!
  • Igen, ha minden inputod (Delphi 7 alatt) szűrt, és az adatbázisodhoz senki más (azaz; nem
    Delphi 7) nem fér hozzá, és minden adatod Windows szervereken megy keresztül (Linux alatt nincs Utf8 BOM) azzal a felsorolt esetek döntő többségét kiszűrheted.
    Mutasd a teljes hozzászólást!
  • nekem szerencsére nem volt ilyen gondom az utf8-cal
    bár eddig mindig tudtam, hogy az e vagy sem, és bemenetkor egyből konvertáltam, így a függvényekkel nem volt gond, kimenetkor meg vissza...
    Mutasd a teljes hozzászólást!
  • Nekem egyedül a Vistával volt gondom, ott bele kellett nyúlni a VCL-be is. Aztán a 7/8/8.1/10-zel semmi problémám nem volt (sőt a Vistás módosításokat később ki is szedtem, mert akinek Vistája van, az annyit is ér:D).

    Viszont a FireBird helyett ajánlanám a PostgreSQL-t.
    Szabványközelibb, megbízhatóbb, jóval többet tud, jobban dokumentált.
    Egy csomó dolgot át lehet vinni SQL oldalra, így kevesebb cuccot kell Delphiben megírni (inkább érdemes SQL-be portolni, mint Lazarusba, vagy újabb Delphibe).

    SQL Feature Comparison
    Mutasd a teljes hozzászólást!
  • Nekem három olyan jellegű gondom volt, ami az AnsiString-ekből, de nem a lokalizációból származott:

    - Az egyik, hogy az Utf8 mostanra sok helyütt de facto szabvánnyá vált, és az angol nyelvű Utf8 Ansinak látszik, amíg vezérlőkarakterbe-, spéci idézőjelbe-, szub/szuperszkriptbe-, stb. nem ütközöl, mikor jönnek a validáción átcsúszó borzalmak. Egyszer belefutottam abba a bugba, hogy az adatbázisban szerepelt egy Utf8 (ként visszakapott) string, ami Ansiként értelmezve tartalmazott egy aposztróf-pontosvessző elemet a közepe felé. (Mire ezt sikerült megtalálni, befontuk a szemöldökünket.)
    - Az Utf8 stingeket kezelheted az Utf8String (as'szem ez volt a neve) típussal, ami azonban csak egy alias az AnsiString-re, ami oda vezet, hogy a legtöbb stringmanipuláló függvénynek (Pos(), SubStr(), Length()) simán beletörik a bicskája, ami alatt azt kell érteni, hogy korántsem biztos, hogy azt csinálják amit szeretnél.
    - Az Utf8 string értelmezhető Ansi-ként, és legrosszabb esetben az (Ord(ch) > 127) karakterek helyén kriksz-krakszok sora jelenik meg, de ez fordítva nem igaz. Ha valami valid Utf8 szöveget vár az inputon és lokalizált Ansi-t kap helyette, simán "mondhatja", hogy az input inkorrekt, és leakadhat. (Az Ansi string mint bytesor értékkészlete nagyobb mint az Utf8-é.)
    Mutasd a teljes hozzászólást!
  • Nem latin2, win1250.
    Pontosabban a windows területi beállítások / "A Unicode szabványt nem támogató programok nyelve " beállítástól függ.
    Nekem sok gondom nem volt azzal, hogy nem unicode a delphi7.
    (Ebben azért közrejátszhat, hogy nem többnyelvű alkalmazásokat írunk.)
    Mutasd a teljes hozzászólást!
  • Hello,

    Lazarust és Delphit is gőzerővel fejlesztik. Elég sok komponens van Lazarushoz is, viszont a reportoknál lesznek gondjaid. 

    A D7 által készített alkalmazások is fognak futni a mai windowsokon is.

    Az xe sorozatot nagyon nem érdemes megvenni - bár vannak nyilvánvaló dolgai, amiket gőzerővel tolnak, mégsem kell elsápadni tőlük. Fordítanak 32 és 64 bitre - a korai xe-k még nem fordítanak 64 bitre. Lehet velük - az újabbakkal - OSX, IOS, Androidra fordítani. Több méretű kijelzőre lehet optimalizálni. Az androidhoz - de gondolom a többi platformhoz is - lehet emulálni, így ez is könnyíti a fejlesztést.
    Mutasd a teljes hozzászólást!
  • Talán annyit tennék hozzá, hogy a Delphi 7 - azon túl, hogy nem fordít 64 bitre - alapértelmezésben 8 bites (ráadásul azt hiszem Latin-2) kódolással kezeli a stringeket, ami egy szekérderéknyi rejtélyes bugot, lokalizációs problémát és hasonlót borítékol.
    Mutasd a teljes hozzászólást!
  • Lazarus -nak csak akkor menj neki ha végtelen időd van és a komponenseidnek megvannak a forrásai, de akkor sem sétagalopp portolni őket. Ellenben a Lazarus -os közösség biztos nagyon értékelné az erőfeszítéseidet. 

    XE: valóban drága, de ha már váltasz és nem te fizeted, akkor vetesd meg. Delphi 10 most 6500 EUR ha nem upgrade, hanem új felhasználó.

    D7: Szerintem csak 32bit -et fordít, de ha ez nem szempont, akkor használd. Windows 7 -el és 8 -al láttam működni, a W10 -hez nem tudok hozzászólni.
    Mutasd a teljes hozzászólást!
  • Pár dolgot próbáltam D7-ből átrakni Lazarusba - hát nem lett tökély :), sőt szopóka - 
    XE nagyon drága, ha eddig jó volt egy régi Delphi is akkor nem éri meg.
    Talán a Delphi 7 volt az ami 'általánosan' legideálisabb volt. A legtöbb komponens is hozzá készült, én még soha nem szívtam vele. Akármi gondod akad vele 2 perc Google...
    Mutasd a teljes hozzászólást!
  • Szia, Lazarus felejtős, XE: nincs, D7 igen.

    Üdv.
    Zoli
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Adott egy Delphi 7-ben speciális területre fejlesztett vállalatirányítási és nyilvántartási rendszer, a készlet és raktárkezelés csak egy kisebb része a funkcióinak, dobozos ternék nem húzható rá.

    Időszerűvé vált az újraírása és a továbbfejlesztése, a használandó fejlesztői környezettel kapcsolatban szeretnék tanácsot kérni.
    Az adatbáziskezelő Firebird lesz, az eredeti rendszer is azt használta, ingyenes, szerverként Linuxra is telepíthető.
    A fejlesztőkörnyezettel vagyok gondban, abban szeretném kérni a tapasztaltabbak tanácsát.
    Delphi, XE vagy Lazarus vonalon gondolkodom, mert a fejlesztésre nem áll végtelen sok idő a rendelkezésemre, és így rengeteg kódot blokkmásolással át tudok hozni.

    Az eredeti programban több vizuális komponencsomag is fel lett használva, az azok által biztosított funkcionalitást és kinézetet szeretném megtartani.

    A Lazarust egyáltalán nem ismerem, a vele kapcsolatos kétségeim:

    - valóban platformfüggetlenül fordíthatóak vele nagyobb, adatbázist kezelő programok is?
    - adatbáziskezelése eléggé kiforrott, negbízható-e(óránként kb. 3000 tranzakció kezelése)?
    - külső komponencsomagok telepíthetőek-e, ill. kiadnak Lazarus kompatibilis csomagokat is?
    - képes Outlook integrációra?
    - levelezőklienssel integráció megvalósítható? Linux alatt is?

    XE:

    - méregdrága, van-e olyan, a W8 vagy W10-es operációs rsz-re vonatkozó kiteljesített funkciója, amelyért érdemes megvenni?

    D7:

    - a lefordított 32 bites alkalmazás fog majd futni gond nélkül a W8-10-es rendszereken is?

    Minden segítő hozzászólást köszönettel fogadok.
    Mutasd a teljes hozzászólást!
abcd