Access ADP SQL adatbázissal optimálisan
2009-09-28T13:17:46+02:00
2010-02-12T15:12:56+01:00
2022-07-19T05:26:56+02:00
  • Érdekelne, hogy mire esett a választásod?


    Mint írtam, egy élő rendszerről van szó, ami több mint 10 év óta fejlesztődik, és sok-sok funkcióval bír, és aránylag gyorsan (pl. egy hétvégén) és fájdalommentesen kellett megoldani az átállást. Ezért első körben Access továbbfejlesztővel szétválasztottam az adatot a kódtól. A kódban aránylag keveset kellett belenyúlni (néhány utasítást, ami SQL szerveren nem használható le kellett mindenütt cserélni), az űrlapok, lekérdezések, jelentések megmaradtak. A táblák csatolt táblákként maradtak az mdb-ben, és igazából továbbra is a microsoft jet hajtja az adatbázist. Előnye viszont ennek a felállásnak az előzőhöz képest, hogy a kódba bármikor bele lehet nyúlni élő környezetben is, nem kell minden felhasználót kiléptetni a programból, ami igen macerás. Ill. a táblákon már lehet különböző sql-finomságokat csinálni (pl. triggerek). Ez most csak egy átmeneti állapot, már készül a teljes kliens-szerver felépítésű változat, azaz egy ADP-t hoztam létre és az DAO kód átírva ADO-ra, access lekérdezések nézetekre, tárolt eljárásokra stb. Üzleti logikán is változtatok közben, így gyakorlatilag egy új program fog elkészülni hamarosan. Ideális igazából az lenne, ha már átírom, hogy Visual Studio-t használjak fejlesztő eszköznek, de maradtam Access ADP-nél (sokak által bírált VBA), hiszen ezt ismerem, és sajnos egy új eszköz bevezetésére nincs megfelelő erőforrás (a napi - nem csak programozási - feladatok, fejlesztések, javítások, problémák, ad-hoc igények mellett sajna).
    Mutasd a teljes hozzászólást!
  • Szia

    Eltelt már egy kis idő, és biztosan döntöttél. Érdekelne, hogy mire esett a választásod?
    Mutasd a teljes hozzászólást!
  • Vonalkód rendszer, olvasó használatára láttam már mdb adatbázist alkalmazni s tökéletesen működött.

    A "többit" meg megoldja az sql server.

    Ha az Access program stabilan működik, az adatbázis szerkezete jó, és a felület jól meg van írva akkor egy fejlesztésnél nem is az adatbázis fejlesztés viszi el az energiát, hanem egy új felület golyóállóvá, vagy éppen "idiotziherré" tétele.

    Zsolt
    Mutasd a teljes hozzászólást!
  • Kérdés az hogy miért kell továbbfejleszteni MS sql adatbázisra... túl nagy lett az adathalmaz, több felhasználó használná egyszerre? vagy jövőben terjeszkedik a cég s távoli elérés kell?


    Több oka is van, azok is, amiket felsoroltál: túl sok felhasználó szeretné mostmár egyszerre használni (ütközések, zárolások); olyan fejlesztéseket vannak tervben, amihez már Access nem a legalkalmasabb (pl. egy komolyabb online vonalkódos raktározási rendszer); az SQL szerver adta lehetőségek kihasználása (triggerek, tárolt eljárások, adatbiztonság) stb.

    Eddig a pontik a napi üzletmenettel kis leállásokkal megoldható amit írsz.


    Köszönöm a leírtakat, a segítséget. Én is gondolkodtam már ilyenfajta átállásban, amikor a meglévő ügymenetet nem túlságosan kell megbontani, de mégis tovább lehet fejleszteni az alkalmazást.
    Mutasd a teljes hozzászólást!
  • Szia,

    Kérdés az hogy miért kell továbbfejleszteni MS sql adatbázisra... túl nag ylett az adathalmaz, több felhasználó használná egyszerre? vagy jövőben terjeszkedik acég s távoli elérés kell?

    Ha meglévő mdb-t kell átírni első választásom az lenne, hogy a táblákat átraknám ms sql adatbázisba, majd becsatolnám a táblákat program indításkor az mdb-be (vagyis mde-be ugye?merthogy nem forrásprogramot használ az user hanem lefordított mde-t...) . Így meg van oldva az űrlapok mögötti táblákba történő szabályozott adatbevitel is.
    Tehát adattáblák sql aatbázisban csatolás miatt sok-sok mdb indítható sok-sok felhasználóval :) s mind-mind látja a friss adatokat...

    Következő lépés access (összefűzött) lekérdezéseket, egyéb üzleti logikát átírni tárolt eljárássá. Majd azokat meg tudod hívni access vb kódból. Access lekérdezésből meghívott Vb functionokat átírni ms sql functionná... stb...

    Ha megvan az ms sql adatbázisban az adattáblák, üzleti logika tárolt eljárásokban, lehet gondolkodni hogy kell-e az access vagy vmi más megjelenítő felület.

    Eddig a pontik a napi üzletmenettel kis leállásokkal megoldható amit írsz.

    Zsolt

    Mutasd a teljes hozzászólást!
  • Igen, ez is benne lehet a megoldásban. A lényeg, mint írtam, hogy minél rövidebb időn belül, minél kevesebb ráfordítással, minél kezelhetőbb programot kapjak. Az Access ADP azért lenne egyszerűbb számomra, mert az eredeti progi adott MDB-ben (pl. egy csomó jelentés), ebben van is némi gyakorlatom, a Visual Studioban (pl.) meg még nem mozgok annyira otthonosan sajnos, ez még plusz erőráfordítást igényel. Delphi-t ismerem és használtam régebben, de kicsit ódzkodom mostanság tőle (támogatottság, bug-ok, drága). Persze nem vetem el ennek lehetőségét sem. Bár igazából ott is megmarad a koncepció felállításának kérdése, hogyan is célszerű az adatokat kezelni: kötött vagy kötetlen adatforrás, direkt kapcsolat az SQL szerverrel vagy egy középső adatmanipuláló rétegen (pl. DLL) keresztül stb?
    Mutasd a teljes hozzászólást!
  • Későbbi továbbfejlesztés esetén (pl. Visual Basic, C# vagy más),

    Bocsi, de én már most ezt választanám.
    Amit megtehetsz ma..
    Mutasd a teljes hozzászólást!
  • Egy meglévő Access MDB adatbázis programot kell továbbfejleszteni MS SQL adatbázisra. Az érdekelne, hogy tapasztaltabbak szerint (akik Access ADP front end/MS SQL back end fejlesztést használnak) hogyan lehet legoptimálisabban megoldani. Olvasgattam, meg próbálgattam többféle módszert, pl. van aki azt javasolja, hogy kötetlen (unbound) alkalmazást célszerű használni, azaz a felület (űrlapok) nincsenek direkt az SQL adatforráshoz kötve, hanem pl. egy tárolt eljárás segítségével "lehúzzák" kliensre az adatokat, és ott lokálban történik a szerkesztgetés, majd a végén visszaküldjük az adatokat SQL adatbázisba. Ill. a legördülő listákat cache-eljük helyi XML-ekbe. Ez jónak hangzik, ha nem változnak gyakran az adatok (pl. termékek, partner adatok), meg nem dolgozik több személy ugyanazon a dolgon. Sajnos nálunk folyamatosan változik minden és mindig mindenki friss információkat szeretne látni és nem akar kézzel frissítgetni.
    Aztán próbáltam az űrlapokat tárolt eljáráson keresztül kapcsolni az adatbázishoz. Itt is jelentkezett egy-két probléma: pl. ha üres rekordforrás rendelődik az űrlaphoz, akkor eltünnek a mezők. Vagy folyamatos űrlapnál volt egy furcsa jelenség: paraméterezett tárolt eljárás volt a rekordforrás, és egy mező módosításakor kiírta a program, hogy a rekord nem felel meg a szűrőfeltételeknek, ezért nem jelenik meg a listán. Újból ráfrissítve persze ismét megjelent a listán.
    Ha sima tábla volt a rekordforrás, és szűrő segítségével szűrtem le az adatokat, akkor jól működött minden, csak sztem akkor lejön a teljes tábla és csak utána történik meg a szűrés, ami megint nem túl jó (pl. hálózati forgalom).
    Aztán olvastam olyat, hogy célszerű 3 rétegű alkalmazást létrehozni, azaz osztálymodulban létrehozni a globális adatelérési objektumokat, eljárásokat, és hogy az alkalmazás ezen keresztül kommunikál (nem direkt) az SQL-szerverrel. Későbbi továbbfejlesztés esetén (pl. Visual Basic, C# vagy más), vagy más felület használata esetén könnyebb lehet az átállás.
    Szó ami szó, nem sorolnám fel az összes problémát, amibe ütköztem, és a lehetséges megoldásokat, amikkel találkoztam, inkább arra lennék kíváncsi, szerintetek mi lenne a legoptimálisabb irány, hogy minél hamarabb, minél jobb, használhatóbb, könnyen karbantartható kliens-szerver adatbázis alkalmazást kapjak a mostani, már kinőtt MDB-ből?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd