Hmmm... metalinken körülnézve 10g Enterprise Edition-re öt találat (Bug Database-ben)
Ebből három Solaris SPARC 64bit-es bug, kettő pedig Red Hat Advanced Server.
A két RH-es és a három Solaris-osból kettő java-hoz kapcsolódik, tehát szintén kicsuknám. Marad az utolsó: az meg valami MMON logban talált 30 percenként hasonló üzeneteket, így ez is kiesőnek láccik...
Esetleg írd meg a pontos környezetet, megpróbálok körülnézni alaposabban, hátha...
Muszáj is, mert éppen egy statisztikai célokat szolgáló segédtáblát akarok csinálni (azt fogja a trigger karbantartani), ciki lenne, ha már a létrehozás közben elromlana
Ezesetben a drop trigger (ek) meg a create trigger (ek) között a jószerencsén múlik, hogy csinál-e valaki DML-t... mondjuk nem _valószínű_ de jobban szeretem azt, ami biztos...
Holtbiztos hogy okoz. Minden DDL okoz, es a drop meg create kezdetuek vastagon DDL-ek.
Gondold meg, ha a create trigger-t atelne a tranzakciod, akkor a tranzakcioban elotte modositott sorokra a trigger lefutna, az utanna modositottakra meg nem. Ez nem kicsit tenne a tranzakciot inkonzisztensse.
Tudja valaki fejből, hogy a "DROP TRIGGER" meg "CREATE TRIGGER" tartalmaz-e implicit COMMIT-ot? Ugyanis én úgy szeretném, ha a LOCK TABLE megmaradna, míg a triggereket ki nem cserélem...
Mintha körben járnánk egy kicsit... _bármit_ észrevehetsz és _bármit_ javíthatsz, csak annyit javaslok, hogy csak akkor javíts, ha biztosan tudod hogy amit beraksz, az jobb mint ami korábban volt.
1. Nem, és nem is vagyok különösöbben szakértője az SQL-nek 2. Szerintem az ilyen előszó jellegű részeket nem igazán érdemes kritizálni, hacsak nem tudsz helyette frappánsabbat, pontosabbat.
Csak ennyi, hogy a 'programozás alapelvei'? Kérlek szépen: a programozás két fontos részből áll: az adatstruktúrák és a kódok megtervezéséből és elkészítéséből.
