Ha úgy érted az update-et, hogy sql-el update-ltem akkor nem. Megadtam a form rekordforrását, majd amikor végzett az ügyfél az adatok szerkesztésével rákattintott az OK gomra és egy save paranccsal (DoCmd.RunCommand acCmdSaveRecord) elmentette. Semmi sql-es machináció nem volt.
A végeredmény: egy adatot egyszerre tetszőleges számú folyamat olvashat, de csak egyetlenegy írhatja. De melyik? Általánosan sok olvasás vagyon, amikből csak néhány akar módosítással folytatódni... legjobban a programozó tudja megmondani, hogy akarja-e zárolni a rekordot vagy sem...
olvasom: tól: "De SELECT esetén kell-e zárolni? ... A végeredmény: egy adatot egyszerre tetszőleges számú folyamat olvashat, de csak egyetlenegy írhatja. " -ig. nekem valahogy ez jon le.
ki fogom probalni:) de ezek szerint, ha kiadom a select * from table-t; akkor azt a tablat senki sem fogja tudni irni amig en a tranzakcioma be nem fejezem? ez eleg lol:)
ajánlom figyelmedbe: http://www.netacademia.net/publikacio/cikk/doc/0202deadlock.doc Soczó Zsolt irta az mssql lockolási mechanizmusáról. Idézek: Ha a zárolási rendszerről beszélünk, óhatatlanul felmerül a gondolat: mely műveletek során van szükség zárak használatára? Az UPDATE, INSERT és DELETE műveleteknél egyértelmű a válasz: adatmódosítás történik, tehát kell a lakat. Ilyenkor az SQL Server úgynevezett exclusive lockot, kizárólagos felhasználásra jogosító zárat tesz az érintett sorra/lapra/táblára (az eszkaláció szerint), s azt a tranzakció végéig fenn is tartja - más még csak nem is olvashatja a megbűvölés alatt álló adatokat. De SELECT esetén kell-e zárolni? Ilyenkor adatmódosítás nyilvánvalóan nem történik - minek ide zár? Ilyen esetben a zárolás célja, hogy lehetetlenné tegye azon adatok módosítását, melyeket éppen olvasunk. Az SQL Serverben alapértelmezésben minden olvasás konzisztens adatokat, lezárt tranzakciók utáni állapotot ad vissza. Erre azért képes, mert minden olvasott sorra/lapra/táblára (az eszkaláció szerint) úgynevezett shared lockot, megosztott zárolást helyez. Azért megosztott, mert egy így zárolt objektumra tetszőleges számú további olvasó csimpaszkodhat, és olvashatja párhuzamosan a többiekkel. A végeredmény: egy adatot egyszerre tetszőleges számú folyamat olvashat, de csak egyetlenegy írhatja.
nem tudom mirol beszelsz, minden normalisnak tekintheto adatbazis ismeri a for updatet. es ez is csak 1 utasitas, csak mssql nem kepes vegrehajtani :D) de a patch cuccot amit irtam elobb, az kivalthatja ezt.
Most megleptél... szerintem teljesen jogos igény, hogy a rekord a lekérdezés és a visszaírás között ne módosuljon... (persze nem úgy képzelem, hogy a lockolás és a feloldás között felhasználói tevékenység legyen)
Akkor bocsánat, én Oracle-t használok, azért gondoltam... kicsit mersterkélt megoldás, hogy egy rekordra szóló kurzort nyitok FOR UPDATE opcióval... és csak az UPDATE után zárom le a kurzort
egyáltalán nem gáz. az sqlnek pont ez a lényege. kérdezel, kapod a választ. utasitasz, végrehajtja. egy sql server több száz ügyfelet is kiszolgál egyszerre. képzeld el, micsoda lockolások lennének, egy idő után. persze lock van, de azt mind a server intézi, és elvileg mindegyik csak rövid időre műx. kivéve a tranzakciókat.
Akkor, ha most jól értem, át kell írnom az egész programot úgy, hogy végig SELECT, DELETE, UPDATE... SQL utasításokkal kommunikáljon a szerverrel...????!!!!
pedig szerintem a for update kell mukodjon mssql 2000-ben is, es nem csak cursor-ra. Ha ez az alapveto dolog sem mukodik benne, akkor az mar gaz:) De akkor max lock-olja a tablat :D) Vagy sajat jelzo bit-el oldja meg a dolgot.
elolvastam, kipróbáltam. a QA ezt mondja rá: FOR UPDATE clause allowed only for DECLARE CURSOR. azaz ez csak arra jó, ha tsql-lel végigmész egy cursoron, akkor arra az időre, amig éppen az adott soron állsz és módositasz, zárolhatod. de ez csak cursorra igaz.
az sql-ben viszont nincs ilyenfajta zárolás. kiadsz egy selectet,, erre kapsz egy adathalmazt. ha vmelyiken módositasz, akkor kiadsz egy update-et. a select és az update között zárolni nem tudsz. csak az irás idejére zárolhatod a sort (illetve nem is te, hanem a server). arról neked kell gondoskodnod, hogy más addig ne irhassa azt a sort (pl újraolvasás, illetve egy tábla, amiben jegyzeteled a kiolvasott sorokat).
Zárolt egy rekord akkor, ha valaki már szerkeszti és másnak nem engedi meg, hogy szerkessze. Tulajdonképpen hibát generál, ha szerkeszteni próbáljuk. Legalábbis az Access-ben. Ugye az Access-ben van pesszimista és optimista zárolás. Én pesszimista zárolást szeretnék elérni.
Mostanában elég furcsa dolgokat produkál az enterprise manager. létrehozok egy táblát. azt mondom neki, hogy jobb gomb, open table, return all rows... erre azt mondja, hogy An unexpected error happened during this operation. [MS Design Tools] - You might not have permission to perform this operation. or the object might no longer exist in the database. Pedig sa vagyok, domain admin, és a tábla is létezik. Ha jobb gombnál azt mondom neki, hogy Return Top... vagy azt, hogy Query, akkor simán megnyitja. Sőt, query módban, ha hozzá akarok adni egy táblát, akkor ezt sem engedi, ugyanez a hibaüzenet. Viszont ugyanezeket a korábban (kb 2 hónappal ezelött) létrehozott táblákkal simán meg tudom tenni. Volt közben egy server-csere (w2k -> w2k3) az sql alatt, és kb azóta van ez az állapot. lehet, hogy ennek köze van hozzá? Találkozott vki ilyennel? és ha igen, sikerült-e megoldania?
Hm, köszönöm a tippet. Már csak az lenne a kérdésem, hogy ezeket a tárolt eljárásokat kívülről, PHPból hogy tudom kiprovokálni? Tudom hogy ez már OFF és bocsi, de hátha erre téved egy guru... :)
Ettől függetlenül lehet, hogy egy ideiglenes oszlop létrehozása, adatmozgatás, régi oszlop törlése és újracsinálása, majd még egy mozgatás lesz a megoldás.
