Aktív témák

• #8 jeges senior tag csika #4

  2004-05-29 21:44:16 #8

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jeges

  senior tag

  válasz csika #4 üzenetére

  bár ezt a filekezelés dógot nem értem, a felhasználónak access-nél is ölég egy internet explorer a megjelenítéshez, és valszeg ez lenne a leegyszerűbb is. :)
  
  
  ez még mindig ugyanaz a projekt? :)
  vagy keverlek csak valakivel? :Y:D
  

• #10 jeges senior tag csika #9

  2004-05-30 08:18:10 #10

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jeges

  senior tag

  válasz csika #9 üzenetére

  hi! :)
  (csak jól emléxem, nem öregszem oly' könnyen :DDD)
  
  adatszerkezethez:
  ''Készletmozgás:
  bevételezés kitölti a saját adatait.
  raktár szintén
  kiszállítás szintén
  Főnöknek meg olyan lekérdezés lenne amelyhez ugye mindhárom tábla kell ...
  Na gondolom ezek külön táblák az világos, de hálózatkezelés kell hozzá, ahhoz meg gőzöm sincs ...''
  
  a fenti azt feltételezi, hogy egy adattáblát csak egy rögzítőfelületen tudsz bővíteni, de ez egyáltalán nem kell, hogy igaz legyen.
  ha van egyetlen, de egységes készletmozgás táblád, ami tartalmazza a bevételezéseket, meg a kiadásokat, akkó' ugyanazt a táblát két felületről kitöltve az egyikkel bevételezel, a másikkal kiadsz.
  
  fájlkezeléshez:
  nem t'om, jól értelek-e, az alapján, amit leírtál a fájlkezelésről, de két megjegyzésem van:
  1. ha nincs formához kötve az adathalmaz, akkó' egyszerűbb lenne eleve accessben megcsinálni, akkó' nincs probléma a táblák összekötéseivel, lekérdezések gyártásával, stb.
  2. ha már léteznek állományok, pl. txt-k, amikre alapozni köll, akkó' is megoldható a dolog. az accessnek vannak jól használható import funkciói, és gombra is kihelyezhetők, akár új táblát akarsz létrehozni, akár bővíteni akarsz egy régebbi táblát.
  
  ie-hez:
  ha jól emléxem, a 98as vagy 2000es verziótól lehet viszonylag egyszerűen exploreres felületeket gyártani accessben, a riportokhoz hasonlóan, de most nincs itthon telepítve access, ezér' nem t'om megnézni...
  
  jogosultságokhoz:
  az access jól tud jogosultságokat kezelni, tehát abszolút jóóól megoldható, hogy jogosultsághoz kösd pl. egy gomb ''enabled'' tulajdonságát.
  (én általában csináltam egy menürendszert, amiben minden gomb csoporthoz vót kötve. be lehetett lépni a programba ''user'' felhasználóval is, de minden le vót tiltva)
  
  soxerencsét! :)
  
  [Szerkesztve]

• #17 jeges senior tag csika #13

  2004-06-02 17:29:38 #17

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jeges

  senior tag

  válasz csika #13 üzenetére

  hi! :)
  
  ''Összesn lehet akkor elég egy mdb file? Vagyis ha ezt teszem fel a szerverre akkor nem is kell file és hálózatkezelés?''
  ha access és többfelhasználós környezet, akkó' célszerű két mdb-t csinálni.
  az egyikbe magát az adatszerkezetet teszed (táblákat), ez lesz a szerver.
  a másikba csak belinkeled a szerver tábláit, és minden mást (riportok, űrlapok, lekérdezések, stb) abba teszel, ez lesz a kliens.
  innentől a ''szerver-adatbázist'' csak a linkeken keresztül látja a kliens, és ami fontosabb, az űrlapok és ripotok (amik sok erőforrást foglalnak) nem a szervert terhelik, hanem a klienst.
  
  ''Ha az adatbázis egyik táblája meg van nyitva írásra, attól még a másik is megnyitható írásra?''
  
  táblákat külön-külön egymástól függetlenül lehet írásra megnyitni
  
  ''Vagy ha meg van nyitva egy tábla írásra, akkor ugyanaz a tábla olvasásra megnyitható? Ha igen akkor mi látszik bennt?''
  
  alapesetben nem, ha egy felhasználó írásra megnyitotta vmelyik táblát, akkó' azt másik felhasználó nem nyithatja meg. ennek elkerülésére is jó az a tmp-tábla szerkezet, amit - ha jól emléxem - a múltkor átbeszéltünk. mivel a felület maga a kliensben lévő tmp-táblát nyitja meg, és írja, ezért csak akkó' van baj, ha két felhasználó ugyanabban a pillanatban nyomja meg az ''OK'' gombot. erre az esetre lekérdezhető minden tábla státusza (sajna a konkrét tulajdonságra már nem emléxem): megnyitott írásra, megnyitott olvasásra, szabad.
  ha a rekord hozzáadása/szerkesztése (azaz a szervernek való átadás) előtt lekérdezed a szerveren lévő tábla státuszát, biztos lehetsz benne, hogy a táblát más nem írja (ha vki olvassa, attól még írhatsz bele, csak az olvasó kliens nem fogja látni a módosítást)
  

• #19 jeges senior tag csika #18

  2004-06-03 12:27:05 #19

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jeges

  senior tag

  válasz csika #18 üzenetére

  nincs mit :)
  
  ha az adatszerkezetet Te határozhatod meg, én továbbra is erőltetném a ki- és bevételezések egységes adattáblában tárolását (de mindenképp érdemes elgondolkodni rajt').
  lehet, hogy a munka elején ez nem tűnik oly' fontosnak, de valszeg sokkal nagyobb problémáid fognak származni a külön táblában kezelésből, mint az egységesből, és ha erre csak akkor jössz rá, mikor már a felületek, lekérdezések, stb. mind elkészültek, az b@szott nagy szívás :U
  még ha a külön táblákkal meg is oldhatók úgy-ahogy a megfelelő riportok, lekérdezések futtatása, akkó' is feleslegesen hosszú ideig tarthat egy-egy ilyen lehívás...gondolj csak egy egészen egyszerű egyenlegre, amit minden alkalommal két alaptáblából köll összevadásznod egyetlen szűrés helyett...:Y
  

• #21 jeges senior tag rdi #20

  2004-06-04 03:24:01 #21

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jeges

  senior tag

  válasz rdi #20 üzenetére

  ''a két mdb esetében a folytonos, vagy gyakori adatfrissítésre is fel kell készülni''
  
  ha lekérdezel, és éppen közben írja vki vmely táblát, azt az egy rekordot nem látod, de ''közel'' online a riport, ez elegendő lehet az esetek 99,9%-ában, gondolom (bár ezt csika kollega jobban tudja :U)
  
  ''ez akkor is igaz, ha a táblák között integrált adtakapcsolat van ? Hogy van akkor, ha egy időben az egyik adathalmazban beírás van, és a másik halmazból pedig adatot vesz át, de közben módosítják a másik halmazban az adot, akkor mi van?''
  
  nem feltétlen értem a problémát, de az accessben sztem teljesen felesleges előre definiálni ''beégetett'' táblakapcsolatokat, ad-hoc módon sokkal egyszerűbb a dolog tapasztalatom szerint.
  a másik, hogy a gyakorlatba' én spec még nem találkoztam olyan helyzettel, amikor ilyen módon összejoinolt táblákba köllött vóna írni, és nem is tartanám célszerűnek a dógot (pont amiatt, mer' teljesen feleslegesnek látom több táblát egyszerre ''megfogni'', mikor ölég egyet is)
  ha arra gondolsz, hogy pl. egy partner id-jét rögzíted egy készletmozgás-rekordhoz, és miközben éppen rögzíted a készletmozgást, a partner adatait vki más módosítja, erre azt mondom, hogy ebből fizikai adatbázis-hiba nem igazán származhat, ha nem engedsz fizikai törlést az adatbázisba' (én nem szoktam), csak központilag indított módon, pl. központi archiválás. emellett ügyviteli eljárásokkal lehet szorosabbra vonni a kontrollt a partneradatok körül, ha szükséges (ezek - ha nem figyelnek oda - egyébként is érzékenyek a duplikációkra, elírásokra, stb.)
  a gyakorlatban úgy nézhet ki a dolog, hogy a partnerek egy legördülő listán vannak feltüntetve, ezt a listát a készletmozgások rögzítőfelületén is lehet frissíthetővé tenni, amennyiben szükséges. ha a készletmozgás rögzítése közben vki módosít a partneradatbázisban, egy ''frissít'' gomb közbeiktatásával update-elhető a lista.
  
  ''Ja és mi van a normálformákkal, ha egy táblán belül vannak a bevételezés és kiadványozás?''
  
  nem látok kapcsolatot a normált formák kialakítása és az egységes készletmozgás-tábla között.
  
  én pl. a következő módon tudném elképzelni a dógot:
  
  km_id - készletmozgás id (elsődleges kulcs)
  ref_id - hivatkozás bizonylatra (idegen kulcs létező bizonylati táblához)
  mdt - mozgás dátuma
  p_id - partner (vevő/szállító) id (idegen kulcs egy létező partner-táblához)
  m_id - bevételezést vagy kiadást végző munkatárs partner id-je (szintén a partner-táblában létező id)
  elojel - a mozgás ''előjele'', iránya (pl. bevétnél 1, kiadásnál 0)
  t_id - termék id (idegen kulcs egy létező termék-táblához)
  menny - bevételezett vagy kiadott mennyiség (természetes mértékegységben)
  status - a mozgás státusza (pl. rögzített, validált (amennyiben ez elvárt), élő, storno, stb. - ízlés szerint)
  rog_dt - rögzítés időpontja
  rog_us - rögzítő felhasználó
  mod_dt - utolsó módosítás dátuma/időpontja
  mod_us - utolsó módosítást végző felhasználó
  
  remélem, nem hagytam ki semmi lényeges infot, persze a tábla bővíthető mindenféle infoval, meg más struktúrák is elképzelhetők, de az adatszerkezet ''magja'' sztem lehet a fentihez hasonló (egyébként se célszerű túlbonyolítani a dógot, mer' valszeg ebbe' a táblába' lesz a legtöbb rekord) :)
  
  hol a probléma a normáltformával? :U

Aktív témák