Cégek, adatbázisok Kettős könyvelés 1.6 © GalaSoft

A program arra készült, hogy egyidejűleg tetszőleges számú céggel tetszőleges számú felhasználó tudjon dolgozni, ahol az egyes cégek adatai különböző adatbázisokban lehetnek (megjegyzés: egy felhasználó egy programban egyidőben egy céget tud megnyitni).

Nos, az első kérdésre azt lehetne válaszolni, hogy ha a programot megvásárló már használ ezek közül egyet (pl. MySql), akkor valószínűleg azt szeretné, hogy a könyvelése is ide kerüljön, azaz az itt használt adatok is ugyanabba a környezetbe kerüljenek, másrészt a végeredmény úgyis az lesz, hogy csak egyféle adatbázist fog használni a vásárló, mert ez a kényelmes és számára a biztonságos, de miért ne választhatna? Ezen kívül a fejlesztés azokat is megcélozta, akik nem hálózatban, hanem mondjuk csak egyetlen gépen egy-két munkatárssal (felváltva) dolgoznak, ahol a könyvelt cégek száma (10-20) és a könyvelési tételek száma is kevés (kb. 1-2 ezer/év).

Mind a különböző adatbázisokban tárolt cégek fontos tulajdonságait, mind pedig a programot használó munkatársakét egyetlen helyen tartja nyilván (galasoftpath) a program, mégpedig a FokFolUserName.gdb, FokFolBusiness.gdb, FokFolBusInfo.gdb, FokFolProg.ini, FokFolRight.ini állományokban.

Ezek az állományok bár text típusúak, de tilos beleírni, mert akkor az ellenőrző összeg eltérő lesz és érvénytelenné válik a bejegyzés (tehát csak a programon keresztül módosítható), ami például a programba belépést, vagy a cég megnyitását teszi lehetetlenné. Lásd.: Cégek kezelése és Program konfig.

A másik fontos útvonal a (businesspath) az adatbázisokban elhelyezkedő cégek útvonala, amennyiben BsdDB és a TextDB adatbázisokról van szó. Ugyanis a BsdDB és a TextDB adatbázis cégenként egy-egy alkönyvtárt jelent ebben a könyvtárban. Ezekben a könyvtárakban lévő az állományok nem olvashatók és módosíthatók.

Tehát a program három útvonalat használ, amiből az első kettőről (galasoftpath, businesspath) a fenntiekben volt szó, a harmadik pedig a kliens munka könyvtár (workpath), ahol a FokFolClient.ini állományt keresi. Ebben a munka könyvtárban találhatók meg a kliens log állományok is, azért több, mert a program naponta hoz létre egy újat. Ezek közül a korábbiakat, amelyek az aktuális dátumnál a beállított (lásd.: Program-konfig) értéknél pl.: 10 napnál régebbiek, pedig automatikusan törli.

MySql adatbázis esetén minden cég egy egy újabb adatbázis. Ez csak egy szóhasználat, mert más adatbázisokban megszokott fogalommal élve ez egy sémának felel meg. Amikor a egy új céget hozunk létre lásd: Új cég felvétele, akkor a program létrehozza magát az adatbázist (sémát) és az összes táblát, valamint az ügyintéző törzsbe bejegyzi a létrehozót teljes jogosultsággal. Ezen kívül feltölti a szemafor, verzió és a struktúra leíró táblát.

PostgreS adatbázis esetén minden cég egy egy újabb séma az adatbázisban. Amikor a egy új céget hozunk létre lásd: Új cég felvétele, akkor a program létrehozza magát az adatbázist és az összes táblát, valamint az ügyintéző törzsbe bejegyzi a létrehozót teljes jogosultsággal. Ezen kívül feltölti a szemafor, verzió és a struktúra leíró táblát.

BsdDB és TextDB esetén már nem valódi adatbázisokról, hanem inkább eszközökről van szó és a programmal együtt, az ebben megvalósított használattal válik csak azzá. Fizikailag elkülönítve, egy-egy könyvtárakban van minden cég tárolva, táblánként külön állományokban. Az új cég felvétele itt sem különbözik az előbb említettektől. Viszont lényeges különbség, hogy BsdDB esetén az indexek is az adatbázisban vannak tárolva, míg TextDB esetén nem, hanem a táblákra történő legelső hivatkozás esetén jönnek létre a memóriában. Tehát a sebesség miatt is fontos, hogy milyen módon érjük el a tárolt cégadatokat.

Az adatokat a kliens programból két módon is elérhetjük. Az egyik az adatelérés közvetlenül mód, amikor a kliens program közvetlenül az adatbázissal kommunikál, míg a másik a szerveren keresztüli adatelérés, amikor a kliens program a szerver programmal tartja a kapcsolatot és a szerver program szolgálja ki az igényeit. Ez utóbbi üzemmódban a szerver programban lehetőség van monitorozni az egyes felhasználókat (munkatársakat, kliens programot használókat), hogy mekkora az adatforgalom, míg a kliens programban elkérhetjük a szerverről a munkatársakat (host, port,...), akikkel kapcsolatot lehet kiépíteni (csevegés, üzenet, fájlküldés).

MySql, PostgreS esetén az adatelérés közvetlenül mód az ajánlott, mert ezek sebességben és biztonság tekintetében is feleslegessé teszik egy szerver közbeiktatását.

TextDB esetén az összesített átbocsátóképesség jobb lesz, mint ha minden egyes felhasználó a adatelérés közvetlenül módot használná.

A mikor a megfelelő programkezelői joggal (programmanager) rendelkező létrehozott egy új céget, akkor elsőként belépteti azokat a felhasználókat, akik eben a cégben várhatóan dolgozni fognak. Ezt az Ügyintézők: cég adatrögzítői menüben teheti meg és csak ki kell választania felhasználót, illetve a hosszú és a rövid nevét beírni.

De minden alkalmazásra igaz, hogy vannak olyan általános, jobbára törzsadatok, melyek vagy nagyon hasonlóak, vagy akár ugyanazok. Ezeket az adatokat a megfelelő helyről, nyilván egy másik cég adataiból ki lehet exportálni, amit ezután az új cégbe importtal beléptetünk. Például a számlatükröt, vagy a felhasználók jogait. Ez utóbbi akkor javasolt, ha valóban kihasználtuk a program nyújtotta lehetőségeket és a felhasználóknak különféle jogokat írtunk egy, vagy több akcióra. Tehát ezeknek az importoknak az előnye, hogy mentesülünk a fárasztó kézzel történő adatbeviteltől.

Valódi adatbázis esetén (MySql, PostgreS) az adatbázis szerverhez kapcsolódás felhasználónév és jelszóval történik. Arra a kérdésre, hogy végül is kinek a nevével és jelszavával történik ez a kapcsolódás a különböző elérési módoknál még nem volt szó. De arról sem, hogy mi történik, ha valaki megváltoztatja a jelszavát, amivel korábban be tudott lépni?

A Program-konfig menüben beállítható az úgynevezett fix felhasználó és jelszó (fix user, fix password) valamint a kapcsolódás típusa (Client / Server). Ez utóbbi azt jelenti, hogy a kapcsolódás az ügyintéző, vagy a fix név és jelszó szerint történjen-e. Amennyiben a fixes kapcsolódás van beállítva, akkor minden adatbázis kapcsolódás ezen a néven történik. Ennek a névnek és jelszónak mindig érvényesnek kell lennie.

Más a helyzet, ha a kapcsolódás típusa Client, vagyis a felhasználó a saját nevével és jelszavával kell, hogy kapcsolódjon. Ha ez sikeres, akkor minden rendben. Ha sikertelen, akkor a program megnézi, belépve a fix user nevével, hogy ennek a felhasználónak van-e bejegyzése a cég ügyintézői táblában, vagyis amúgy jogosult lenne a belépésre és ha igen, akkor megadja ezeket a jogokat a kiválasztott adatbázisban, sémában, majd bontja a kapcsolatot és újra elindítja a belépési procedúrát.

Erre azért van szükség, mert ha a felhasználó megváltoztatja a jelszavát, akkor a következő saját névvel történő adatbázis kapcsolódás biztosan sikertelen lesz, márpedig a jelszócsere alkalmával nem lehet ezt azonnal adatbázis szinten is átvezetni, hiszen akár cég sincs megnyitva (azaz nincs adatbázis kapcsolat) a jelszó csere folyamán, vagy többféle adatbázis is használható a különböző cégeknél.

BsdDB és TextDB esetén, az adatbázisok, vagyis a könyvtárakban tárolt állományok nem igazán olvasható állományok, de illetéktelen felülírás ellen védeni kell ezeket, illetve mentéseket kell végezni. Ezt a programon keresztül érdemes megtenni, lásd.: Archíválás, biztonsági mentés menüben. Ezek az archíválással készült állományok már olvashatók, tehát illetéktelenek elől jól elkülönítve tárolandók.

MySql és PostgreS esetében fájlszinten szintén nem olvasható el semmi lényeges. Itt is érdemes archíválási céllal mentéseket végezni.

Itt viszont egy még felmerülhet az a kérdés is, mi van akkor, ha egy munkatárs ismeri az SQL-t, és az adatbázis egyéb parancsait és a programon kívül belép az adatbázisba, ugyanis a program használatával a cégek sémáiban minden jogot megkapott. Nos ebben az esetben az ilyen munkához való programokat, információkat kell az ilyen munkatárs elől elzárni.

Végezetül, amennyiben programon kívüli mentést szeretnénk végezni (hátha valaki ilyet akar), akkor BsdDB és TextDB esetén mindig vigyázni kell, hogy senki se dolgozzon abban az időben a cég adataival, valamint a teljes könyvtár tartalmát kell elmenteni. MySql és PostgreS esetében pedig az adatbázis e célra szolgáló programjait lehet használni.