19: Ha így lenne, akkor a LOCK-ot szerinted minek találták fel?

Na jó, egészen pontosan fogalmazva:
Közöltem haverral, hogy szerintem meg van oldva a probléma, azóta tesztelgeti, és nem jelezte vissza, hogy még mindig hibás lenne a cucc. :)

19-es: Ne legyél okosabb a tapasztalatnál. :)))))
Én LÁTOM, hogy ez megoldotta a problémát.

A belenyúlás megoldotta a problémát? :)

Hülye ez a gyerek vazze. Az adatbáziskezelő rendszer sorba rendezi a processzeket ezek átlag 3 ezred másodperc alatt lefutnak. Mi a faszom befolyással lenne a tranzakcióba fogás bármire? Miért vissza kell görgetni a tranzakciót? Izolációs szintek kellettek hogy lefusson a kérés? Mer az gyorsabb? Na fiam te se laszel már hülyébb.

Szerintem nincs ebben semmi extra. Sajnos a legtöbb kollega semmilyen formában nem figyel oda a tranzakciókezelésre, én is rengeteg kódot láttam már ami gány. Nekem csak az az érdekes, hogy ez miért érdemel egy ekkora bejegyzést? Sztem 5 sorba le bírtad volna írni, így meg született megint egy önajnározó cikk.

Ne arcoskodjál öcsém még programozót sem láttál életedben nemhogy programot. Nehogymár előadd magad itt ajax-al meg php-vel me mysql-el mert felruglak mit paraszt a lószart. Hülyegyerekek szórakoznak evvel a hányással. Na most kiállítottad a szegénységi bizonyítványod. Fasszom idióta.

k0zi: MySQL-re írták.
15-ös: Ezt már leírtam. Úgy "működik" a hiba, hogy rendben frissül a lista, de mást jelez ki ennek vezetőjeként a másik képernyőterületen, mint aki valójában vezeti, holott ennek a két dolognak szinkronban kellene lennie egymással.

"9-es. Ja, lehet utólagos ellenőrzést is beilleszteni.
Csak az még egy plusz lekérdezés."

Meg az sem kell a legtobbszor, irj egy peldat, amikor szerinted elromlik az adatbazis attol, hogy felvaltva hajtodnak vegre utasitasok. Olyat, hogy eppen jon az aramszunet most ne irj.

"Az első fele az első felhasználó adataival hajtódik végre, a második fele a második felhasználóéval, végeredményként pedig megkapjuk a hibát: nem lesz szinkronban a lista és az azt vezető felhasználót tároló adatrekord."

Tehat erre mondj egy peldat vagy esetleg ird le, abban a programban, amit neztel, ez hogyan mukodik.

sodika: olyanra gondoltam hogy ha req az oracle, abban van autocommit on kapcsoló és lehet azzal nem jönnek elő ezek a hibák :)

Lehet, hogy négyesre írták, és csak az ötösben van tranzakciókezelés? Hmmm. Szerintem van a négyesben is. Vagy nincs?

Milyen SQL szerverre írták? (hivatalos req)

9-es. Ja, lehet utólagos ellenőrzést is beilleszteni.
Csak az még egy plusz lekérdezés.
k0zi: Á, amíg nem indul el a weblap, üzleti titok, hogy pontosan miről van szó. :)

sodika: milyen rendszer ez? link plz

Az sem igaz, hogy utasitasok egy halmazat mindenkeppen tranzakcioba kell tenni, hogy az adatbazis konziszens maradjon.

"esetleg BCNF-ben"
Ez tényleg lehet egy lehetséges magyarázat.
Ennyire nem ástam bele magam a rendszerbe. :)

Ha konkretan megmutatod a tablak felepitest, megmondom miert olyan az adatabzis, amilyen. Az amit eddig leirtal abban nincs eleg informacio, csak sok ondicseret, hogy milyen okos vagy.

"Vajon mi a ványadt fenéért írja be a cucc egyszerre ugyanazt több táblába is? "

Attol fugg, mi az az ugyanaz. Lehet, hogy a tablak 3NF-ben (3-as normalforma) vagy esetleg BCNF-ben (Boyce-Codd normalforma) vannak, ami adott esetben novelheti a rendundanciat a tablakban, viszont csokkentheti a tablak meretet, ami nagyon fontos hatekonysag novelo lehet pl. join muveletnel vagy tablaszorzasnal, vagy barmilyen mas muveletnel.

"tudatosan sugárzott szerénység"

Sodi, te a büdös életben nem voltál szerény.... :D

Hát, nem is lesz neki túl jó ajánlólevél ... :)

De vazz, a csávó ezt a rendszert több száz dollárért árulja :))

Az se mindegy, az ember kitől vásárol szoftvert.
Normális helyeken pl. garancia is jár. Nálunk például egy évre.

Ha annyi külsős által készített sz@rt kéne gatyába ráznod állandóan, mint nekem, akkor ilyeneken meg se lepődnél :)

1. Igazad van, láma volt a kódoló.
2. Aki nem dolgozik, az nem is hibázik.