számlaszám kiosztás Karakas Gyula
az előadásról örök probléma „kedvenc” listatéma, flame többféle megvalósítás file, C/S, multitier nincs egy üdvözítő megoldás vitaindító
számlaszám egyedi, kihagyásmentes, egyesével növekvő azonosító tipikusan emberi feldolgozásra gépi feldolgozásra példa: TCP csomagok nemcsak számlaszám, hanem bármilyen bizonylatsorszám számlaszám APEH miatt lényegbevágó
követelmények egyedi, kihagyásmentes, egyesével növekvő számozás nem kell felvitel közben látni a számlaszámot az adatok felvitele és számlaszám kiosztás két külön művelet gyakorlatilag csak akkor kell számlaszám, ha nyomtatunk lehet a felvitel után egyből osztani a számot, ekkor egy műveletnek látszik a felhasználó szemszögéből
file megosztásos környezet dBase, Paradox etc. megoldások table lock „Gizike, lépjen már ki a számlázóból!” segédtábla, rekord lock azonosító: „számla” érték: a következő kiosztandó számlaszám
client-server SQL server megoldások select max(szamlaszam) unique index a szamlaszam mezőre! segédtábla tranzakció kezelési problémákat fel kell oldani egyszerre akarják kiosztani a számlaszámot valaki szerkesztette a számlát, közben más kinyomtatja
multi tier web, CDS stb. jóslat: a webes alkalmazások feljönnek mint a talajvíz,.net webforms és társai tranzakció problémák egyszerre akarnak számlaszámot osztani valaki szerkesztette a számlát, amit időközben kinyomtatttak megoldások az üzleti logika réteg megoldja (saját megoldás: sorszámkiosztó objektum, segédtáblával)
konklúzió file sharing-ot felejtsük el (nem korszerű) nem az a baj, hogy nem „divatos”, hanem a meglevő tudást többször használhatod NEM a számlaszám az egyedi kulcs az csak egy azonosító, aminek kiosztása egyedi. a fenti technikákkal ez több párhuzamos tranzakció esetén is az SQL server lock managerével kezelhető számlaszám kiosztás nem az adatfelvitel tranzakcióban van
megoldatlan probléma APEH ide vagy oda, a program készítője _mindig_ fog tudni generálni mindenféle számlát