Keresés

Részletes keresés

mikkkro Creative Commons License 2007.07.04 0 0 2414
szerintem te értesz félre valamit nagyon, a redo log sem instance-hoz tartozik. hány db redo logod van? instance-onként x db? nem, a redo log egy adott adatbázishoz tartozik és kötelező is a közös diskrendszeren tárolni.
Előzmény: Törölt nick (2413)
mikkkro Creative Commons License 2007.07.04 0 0 2412
előre megkövetlek, ha én mondom a botorságot, de hogy érted, hogy az archive logok az instance-hoz tartoznak? szerintem pedig az adatbázishoz tartoznak, globál, az, hogy hova, milyen formátumban mented az archive logokat, az is egy adatbázisparaméter, és pl. 4 clusternode-on nem négyfelé menti őket, kivéve akkor, ha direkt multiplikálva, több helyre archiválsz (tehát nem a közös diskterületre). erről van szó nálatok?
egyáltalán milyen módszerrel, eszközzel mentesz?
Előzmény: Törölt nick (2411)
mikkkro Creative Commons License 2007.07.04 0 0 2410
mire gondolsz? így hirtelen hajnalban szerintem pont ugyanúgy kell archive logolni, meg azokat menteni is racon meg single instance-on. nálunk legalábbis nem merült fel különbség.
Előzmény: Törölt nick (2408)
KingFishR Creative Commons License 2007.07.04 0 0 2409
Köszi a javítást.

Nem szeretem a Tablespace Compression kifejezést, mivel arra utal, hogy valami táblatér szintű dologról van szó - miközben az Oracle még a táblán belül is blockonként dönti el, hogy az adott blokkra alkalmazzon-e "compression"-t, vagy sem. A tablespace-re adott compress opció csak egy default érték, amit simán felül lehet bírálni create table-nél vagy move-nál egy nocompress-szel. Az indexnél alkalmazott key compression-nek pedig nem sok köze a táblánál alkalmazott compression-höz. És nem jutott eszembe a "data segment compression", ezért írtam, hogy "datablock compression".

11g-ben az egyik new feature, hogy a data segment compression használható lesz OLTP rendszerben is! Ez minimum 2 dolgot kell jelentsen:
- sima insertnél is megy a compress
- nem degradálja az update sebességét annyira, mint most 9i2-ben (1/3-1/5 sebességet mértünk teszteknél).
Gondolom erre azért van szükség, mert a DB2 Viper-ben a compression már most is használható általános esetben, ráadásul több esetben 2x olyan jól tömörít, mint az Oracle (azonos adaton).

Köszi a tanácsot.
Kérdés, hogy hogyan lehet megvalósítani a táblafüggvényeket, hogy közben a teljesítmény ne csökkenjen a forall-os verzióhoz képest. Lehet kombinálni a két dolgot?

Előzmény: lakotars (2396)
tnsnames.ora Creative Commons License 2007.07.03 0 0 2407
>Így x év Warehouse Builder használat után érteni vélem, hogy utálod. De a 10gR2-es verziót is ?

Nézd, senki nem mondta, hogy nem fejlődött az évek során és nem lett egyre jobb a termék. Azt is tudnod kell, hogy már lassan 1 éve kiestem OWB-s témákból, a 10gr2-es verziót nem is láttam még konkréten.

Az OWB-utálatomnak vannak objektív tényalapú vonzatai és vitatható szubjektív vonzatai (->hiába ajánlasz nekem egy neked szép nőt, ha nekem ronda, nem fogsz tudni rádumálni... ;).

Ami a ténybeli dolgokat ileti:
- Az Oracle vérlázítóan aljas módon félig se kidolgozott koncepciók alapján extra bugos verziókat hozott ki az elején, nemegyszer. Azért minősítem aljasnak az eljárását, mert a megtévesztett vásárlókkal finanszíroztatta meg saját termékének fejlesztését. Én láttam, ahogyan a hivatalos Oracle-s OWB-ben fejlesztő konzultások vért p*sálnak a fejlesztéssel. Nekem senki ne mondja, hogy egy account profile (számlaszintű aggregáció) kilenc emberhónapnyi munkát igényel normális termékkel, nem mondom meg mikori és mennyi tízmillióért.
- Nagyon komoly tudásbeli különbség volt - gyárilag előre beprogramozva? - egy hivatalos Oracle-s OWB-s között és amit földi halandó maga elérhetett -> és ezt objektív infók alapján mondom! Őket hihetetlen mennyiségű megfizethetetlen belső infók támogatták (a fentiekből kifolyólag is). Szubjektíve nekem sz*r érzés volt _bizonyítva_ látni mennyire kevés lehetek a teljes bugelhárításos OWB-s fejlesztési ciklushoz _perspektivikusan_ is!!
- A repository-technológia miatti különféle verzió-migrációkról ne is beszéljünk; iszonyú költségeket jelentettek mindig is, sokszor értelmetlenül, és megmagyarázhatatlanul.
- Hardver-igényben az indokoltnál nagyobb overheadet jelentett az OWB-s alkalmazás a kézzelírotthoz képest.

Ami a szubjektív részt illeti. Én azt gondolom, hogy
- A repository-technológia (designer, discoverer, owb stb.), alapvetően elhibázott koncepció. Ráadásul extra mennyiségű bugot bírt általa produkálni az Oracle.
- Míg a fejlesztői igényeket mindig is jobban támogatta az OWB, az üzemeltetési/ monitorozási támogatás az én ízlésem szerint sokkal gyatrább volt. Komoly hackeléseket igényelt mindig is a téma.
- Valami elképesztően trágya debugolhatatlan kódot generál az OWB. Már amikor lefordul ugye, mert volt olyan, hogy bug miatt lefordíthatatlan kódot generált. Lássuk be generált kódba visszatérően kézzel belenyúlni, nem túl gusztusos mutatvány.
- Azt gondolom annak a fajta vizualitásnak amit az OWB nyújt nincs sok teteje. Félreértések elkerülése végett, van amikor szerintem is létfontosságú a vizualitás, például egy adatbányász streaming manipulálásakor (Clementine, SAS), de amikor százas nagyságrendű attributumot kell egybelátni mappingek sorozatán át, ott hatékonyabb lehet a nonvisual eszközkészlet. Tudom, kiterjedten lehet programozni is az OWB-repot: mégis ahogy én a OWB-konzultásokat elnéztem ezt igen kevéssé tették mindig is.
- Egy ilyen eszköznek wing-to-wing folyamat egyetlen eszközének kell lennie, amibe a tudást nem-technikai üzleti emberek is bele tudják vinni (pl.: vállalati adatszótár). Az OWB tudtommal ezt még most se produkálja szemben a BO-val/SAS-sal/Terratec-kel és a többiekkel.

Összefoglalva, azt gondolom adattárházat építeni nagyon jó dolog, például mert nagy profitot lehet belöle kisajtolni. Nagyon drága mulatság is lehet mind a felépítése, mind az elbaltázása az évek során. Azt gondolom lehet jól és jó adattárházat építeni, de meg kell hozzá találni az optimális tervezési és üzemeltetési folyamatokat amik sokkal lényegesebb kérdések mint az OWN/non-OWB kérdéskör. Az számomra nem kérdés, hogy a multinacionális Oracle az OWB-vel a saját marketing érdekeit sokkal előrébb helyezte ügyfelei érdekénél, ráadásul éveken át. Életem egy fontos szakaszára ez maradéktalanul rányomta bélyegét, ezért sose fogom szeretni az OWB-t. Nem azt mondom, hogy rossz termék (bár csak néhány belém beégett rossz tapasztalatot írtam le). Csak azt mondom, hogy utálom.
Előzmény: Pendragon (2406)
Pendragon Creative Commons License 2007.07.03 0 0 2406
Csak kíváncsiság :
Így x év Warehouse Builder használat után érteni vélem, hogy utálod. De a 10gR2-es verziót is ?
Előzmény: tnsnames.ora (2391)
kissbe1234 Creative Commons License 2007.07.03 0 0 2405
Köszi a hozzászólásokat, közben megoldódott a kérdés, valóban a group by grouping sets kellett.

Üdv: Kiss Balázs
Előzmény: lob (2404)
lob Creative Commons License 2007.07.03 0 0 2404

Szia!

sql*plus-nak van riportkészítési lehetőségei.

A Te esetedben valami hasonló :

break on dátum skip 1;

compute sum label 'Összesítés adott napra ' of összeg on dátum;

select * from tabla;

 

clear break;

clear compute;

 

Üdv.

LOB.

Előzmény: kissbe1234 (2400)
lakotars Creative Commons License 2007.07.03 0 0 2403
Próbálkozz a Group By parancs Rollup és Cube kiterjesztésével, ezek pont arra ez esetre vannak kitalálva, ha a lekérdezésbe összegző sorokat is szeretnél. Nem biztos, hogy pont olyan formában, ahogy szeretnéd, de megnézni érdemes.
Előzmény: kissbe1234 (2400)
halaloszto Creative Commons License 2007.07.03 0 0 2402
Vagy vannak a temporary tablak/viewok, csak nem emlekszem a nevere es a szintakszisra sem :-)

vajk
Előzmény: NevemTeve (2401)
NevemTeve Creative Commons License 2007.07.03 0 0 2401
Nem az ilyesmit szokás a kliensoldali programban megoldani? Vagy, ha például a végfelhasználó Sql*Plus-t használ, akkor Pl/Sql eljárást lehetne használni...
Előzmény: kissbe1234 (2400)
kissbe1234 Creative Commons License 2007.07.03 0 0 2400
Hello!

Megpróbálom jobban leírni.

A select eredménye például:

Dátum Azonosító Összeg
------------------------------------------
2007.03.12. az1 2000
2007.03.12. az2 3000
2007.03.12. az2 -500
2007.07.21. az3 300


A következő szeretném látni:

Megjegyzés Dátum Azonosító Összeg
--------------------------------------------------------------------------
2007.03.12. az1 2000
2007.03.12. az2 3000
2007.03.12. az2 -500
Összesítés adott napra 2007.03.12. 4500
2007.07.21. az3 300
Összesítés adott napra 2007.07.21. 300
Összesítés időszakra 4800

Lehet, hogy valahogy el kellene tárolni az eredményt, de a temporary tábla nem jó a pragmák miatt.
Előzmény: crockl (2399)
crockl Creative Commons License 2007.07.02 0 0 2399
es megis, mire osszesitenel es hogyan?
peldaul: select sum(osszeg),to_char('YYYYMMDD',datum) as datum from tabla group by to_char('YYYYMMDD',datum) ? Ami mondjuk osszesiti napok alapjan az osszeget. Talan ha leirnad mit is szeretnel, de ugy, hogy tudod mi nem tudjuk neked mi van a fejedbe ;)
Előzmény: kissbe1234 (2398)
kissbe1234 Creative Commons License 2007.07.02 0 0 2398
Sziasztok!

A problémám a következő:

Van egy lassú selectem, ami lehoz egy táblát
- dátum, azonosító, összeg

szeretnék ebbe dátum szerinit összesítő sort beszúrni, majd egy teljes összesítést is elkerülve azt, hogy újra le kelljen kérdezni, vagy el kelljen tárolni a select eredményét

Valakinek tippje?

Kösz: Kiss Balázs
tnsnames.ora Creative Commons License 2007.06.30 0 0 2397
WOW. Nagyszerű és profi hozzászólás. Még jó hogy nem okoskodtam túl az append hintes dolgot... :o)
Előzmény: lakotars (2396)
lakotars Creative Commons License 2007.06.29 0 0 2396
"Datablock compression" tényleg nincs, de Data Block Compression van. Sőt, Data Segment Compression is, ami ugyanaz. Tényleg emlegetik Tablespace Compression néven is, bár lehet tábla szinten is használni.

Az append hint említese nem tévedés. A tömörítés tényleges feltétele a direct path betöltő művelet használata, ami lehet SQL*Loader direct módban vagy insert /* +APPEND */. Mindkét esetben a lényeg, hogy nem a blokkok belsejében keresgélünk szabad helyeket, hanm a HWM fölé írunk teljes formázott blokkokat.

A konkrét kérdésre az én tanácsom: Ha tényleg kell a PL/SQL a transzformációkhoz, akkor írd meg az eljárásokat táblafüggvényként. Ha ez megvan, akkor a töltés már mehet insert append módban, kompresszió-kompatibilisen.

Előzmény: tnsnames.ora (2391)
edesviz Creative Commons License 2007.06.29 0 0 2395
Sziasztok,
még egy szép anomáliát értem meg, a "*"-gal. 3 szintű rendszer volt speciális snapshotokkal, triggerekkel. Egy "Worldwide" szerver, regiónális szerverek "around World", és a felhasználók saját notebookja, Oracle lite-tal. Elvileg a local gépen páros, a konszolidált adat páratlan kucsú volt, és rögzíthették délamerikában az európai adatatot. A notebook két üzemmódban működött, halózatnélkül saját db-vel, vagy a cégben dockstation-ban, a regiónális szerverrel. Amásdikesetben a háttérben megkezdődött a 2 db szinkronja. Illetve regiók folyamotosan szinkronizáltak a Központon keresztül. A sziknronizálókban volt select *. A folyamatos db definiciós változások is meg voltak oldva, csak egy bibi volt. Ha egy új reginális szervert beállítottak, mert pl Újzéland levállt Ausztráliáról, a legfrisseb db sémát gyurták bele. A mezők mind meg voltak, csak a sorrend nem stimmelt. A kolléga szépen logikai rendbe rendezte designerrel a táblákat, és nem felelt meg alter add.., alter drop rendeknek. Tehát a predefinit inerfészeket jobb kultiválni. Ha sok vele a munka a fejlesztésnél, akkor is.
Édesviz
Előzmény: tnsnames.ora (2393)
tnsnames.ora Creative Commons License 2007.06.29 0 0 2394
>>>>>>>>>>>>>
Ha ennek a táblának a szerkezetét egy mezővel bővítjük, akkor elvileg az összes rá mutató hivatkozást is módosítani kell; ami alól szerintem csak egy olyan trigger használata mentesíthet, amely az adattáblára hivatkozásokat figyeli, és szintaktikailag hibás hivatkozások paramétereit átadja egy szintaktikailag helyes hivatkozásnak és a hiányzó paramétereknek NULL értéket ad. Ez a trigger csak akkor adna vissza hibaüzenetet, ha egy olyan adat hiányzik, amelynek nem lehet NULL értéket adni.
>>>>>>>>>>>>>

Ez szerintem több szempontból sem működőképes: mit csinálsz például a plsql eljárásokban lévő stringből összerakott dinamikus sql-ekkel? Azaz nem elég a szintaktikus "garancia" kellhet a szemantikus jóság garantálása is.

Szerintem nagy rendszernél általános esetben nem egy automatikus trigger a jó megoldás, noha készséggel elismerem speciális 'redukált' esetben egy jó támogató rutint lehet írni e célból...

Hanem inkább:

- dokumentálás (esetleg előzetes tervezéssel ;).

- ha nem áll rendelkezésre az előbbi (pl.: megbízhatóan, jó minőségben, up-to-date-n), akkor sokat segíthet egy okos és következetes kódolási konvenció, a könnyű kereshetőséget támogatandó.

- Zárógondolat: megnézném magamnak azt az üzemeltetést, ahol egy ilyen automatikus triggert átvennének üzemeltetésre és nyugodtan tudnának felöle aludni... ;)
Előzmény: Pathmaster (2382)
tnsnames.ora Creative Commons License 2007.06.29 0 0 2393
>amikor megnyugodva jelenthettük, mint fejlesztők, hogy egyetlen társunk se esett avészes rövidítés bűnébe.

Nem tudom pontosan ekörül forog-e a thread, de szerintem

- pl.: insert (select)-eknél a kötött definiált mezőlista melegen ajánlott... Az meg nézőpont kérdése, hogy mi a jobb, ha működnek a feldolgozási folymatok a háttérben a maguk rugalmasságában (és a változásokról a feldolgozás során akár nem is értesülünk), avagy jöjjenek kőkeményen a hibaüzenetek - dagadtra hízó naplók formájában -, akár egyetlen új oszlop hozzáadásakor is, mert hiszen az valamiféle potenciális anomáliát jelent.

- Ha rendszerek közti (és nem rendszeren belüli, hisz az speciális egyszerűbb eset) az ilyen típusú feldolgozás, akkor én a felelősségmegosztásban gondolkodás híve vagyok. Az 'exporter' is tudja pontosan mit ad, az 'importer' is tudja pontosan mit vesz át. És ezen 'interface' mögött mindenki tudja a saját rendszer-bizniszét csinálni, akár az OO-paradigma jegyében is.
Előzmény: edesviz (2388)
tnsnames.ora Creative Commons License 2007.06.29 0 0 2392
Visszakérdezek... Jogosultság-kiadásnál nem ugyanez a helyzet? Ha A usernek oda akarom adni B user tábláinak olvasási jogát, akkor a jogosultságadás pillanata után keletkezett újabb B sémás táblákat szintén nem fogja látni A user külön explicit grant nélkül. Nézőpont kérdése, hogy helyes-e ez a filozófia, én (is) biztosan berzenkedem tőle.... ;)
Előzmény: NevemTeve (2389)
tnsnames.ora Creative Commons License 2007.06.29 0 0 2391
Hát ahogy a közmondás mondja, ugatós kutya legyek, ha értem a kérdést... ;)

Oracle "Datablock Compression"? Nekem egy találat sem jött ki a gugliból. Én amire gondolni tudok az a tablespace compression, ami szerintem amúgy nagy találmány. Némi plusz CPU művelet árán, átlagosan akár 50%-kal csökkenthetődnek a nagyon költséges blokk-műveletek. (Hiszen feleannyi tárfoglalás, feleannyi blokkírást és -olvasást vonhat maga után pl.: full scan esetén)

Nem tudom ki állította neked, hogy "mindenképp szükséges" plsql-kód: az én tapasztalatom szerint lehet hatékonyan pusztán sql-ben is abszolválni az ilyen dolgokat. És számtalan előnye van az átláthatóságtól, a módosíthatóságon keresztül a hatékonysági kérdésekig. És még keretrendszert is könnyű abszolválni hozzá...;) Zárójelben megjegyezném, ahogy több transzformáló sql gyorsabb lehet egyetlen plsql-es átemelésnél, úgy egyetlen jól megírt plsql-blokk is kenterbe tud verni egy sql-t végrehajtási idő vonatkozásában. Mint ahogy az én tapasztalatom az is, hogy minden eljárás majdhogynem mindig továbboptimalizálható: ahogy nincs olyan túratáska, amibe ne férne el még plusz egy kenyér, csak akarni kell... :o))

Szerintem Guinness-rekorder vagyok Oracle Warehouse Builder utálatban ;), de azt meggyőzödéssel állítom, hogy a legmagasabb szinten a legkomolyabban implementálta mindazt a tudást az Oracle e szoftverében, amit saját rdbms-ről gondol & tud. Következésképp érdemes lehet megnézni, hogy egy generált OWB plsql mapping mit és hogyan csinál. És ez talán nem egy nagy erőfeszítés, főleg, ha csak a demókat megböngészi az ember (és nem kísérel meg saját maga egyet kikínlódni)

Append hint tömörítene? Nincs itt valami keveredés? Az én tudtommal ez egy performancia hint, hogy az insert _gyorsabban_ történjen, a HWM (High Watermark) egyszerű áthelyezésével, utólagos indexépítéssel stb. Némileg hasonlóan az sqlldr direct path-os töltéséhez.

Hintekkel kapcoslatos alapszabály, hogy az sql-optimizer mindig figyelembe veszi a hintet, HA TUDJA(!!)

bulk collection-t meg forall igen hasznos plsql nyelvi eszközök. Érdemes velük foglalkozni mind statikus mind dinamikus sql esetében, szerintem is

Az én javaslatom: próbáld meg újra fogalmazni a kérdésedet, akkor könnyebben kaphatsz választ...
Előzmény: KingFishR (2390)
KingFishR Creative Commons License 2007.06.29 0 0 2390
Datablock Compression kérdés:
Hogyan lehet compress-el kompatibilissá alakítani PL/SQL processeket, amik Oracle (ajánlás szerint) bulk collection-t meg forall-t használnak nagyobb tömegű adatok ellenőrzött áttöltésére. Közben természetesen mindenféle adatösszeszedést, adatoknverziót, mappinget, adatellenőrzést hajtanak végre, tehát mindenképp szükséges a PL/SQL kód, nem lehet insert /*+append*/ select-et használni.
Megpróbáltam, hogy a forall-os insertbe beírtam az append-et, de nem tömörített :( (pedig a trace-ben látszott, hogy 5000 soronként hajtott csak végre insertet és bene is volt az append, de sajnos "insert /*+ append */ into x values..." formában szerepelt, és úgy látszik, erre nem kapcsolt az SQL, hogy akár meg is csinálhatná az append-et.
Elvileg 11g-ben majd ez már fog menni, de most 9.2-őn vagyunk :(
Bármilyen ötletet szívesen fogadok :)

Pl. nem lehetne index nélkül hivatkozni a memőriatömbökre, mint forrásra és így kinyomni belőlük a táblába az adatokat?
NevemTeve Creative Commons License 2007.06.29 0 0 2389
A VIEW-val én is megjártam, azt hittem, tényleg az tárolódik az Oracle lelkében, hogy "SELECT *", de nem, hanem a "CREATE VIEW" pillanatában létező mezők listája... tehát ha új mező jön be, akkor a ilyen "SELECT *"-os VIEW-kat is "CREATE OR REPLACE"-olni kell.
Előzmény: edesviz (2388)
edesviz Creative Commons License 2007.06.28 0 0 2388
Sziasztok,
persze, hogy kontextus függő, pl egy sub select-ben exist mögött még lehetne * is, de ha simán áll egy view-ban, akkor a view is megváltozik. Nekem már volt olyan feladatom, hogy saját rendszernél, már működött vagy 3 éve, több százezer, közelítőleg milliónyi vegyes forrássorból kellett kikereseni a "select *" kifejezéseket. Az ártóakat, és nem ártóakat. Illetve volt olyan is, amikor megnyugodva jelenthettük, mint fejlesztők, hogy egyetlen társunk se esett avészes rövidítés bűnébe.
Édesviz
Előzmény: NevemTeve (2387)
NevemTeve Creative Commons License 2007.06.28 0 0 2387
Kontextustól függ. Pro*C-ben ilyenkor ORA-nemtudommennyi-t kapok, ha viszont egy SYSREFCURSOR-om van, amit a PL/SQL-től kaptam, és abból nem olvasok ki minden mezőt a FETCH-ben, az nem okoz gondot.
Előzmény: crockl (2386)
crockl Creative Commons License 2007.06.28 0 0 2386
miert ne futna le a select * ? Az mar az alkalmazas kerdese, hogy mit kezd vele, hogy 1el tobb mezot is visszaad mint eddig.
Előzmény: edesviz (2384)
Pathmaster Creative Commons License 2007.06.28 0 0 2385
Ezek szerint a tábla szerkezetének a bővítése nem okoz hibát azokban hivatkozásokban, amelyek nem érintik az új mezőt. (A SELECT * pedig kerülendő.)

Köszi:)
Előzmény: NevemTeve (2383)
edesviz Creative Commons License 2007.06.28 0 0 2384

Szia,

lehet a mező defaultja null, tehát az összes insert, update delete, futni fog,

csak a select * nem.

Én inkább egy párhuazmos táblát készítenék, kulcs duplikációval, és uj mezővel, mezőkkel. a trigger készítéshez pedig create or replace trigger utesítást ajánlanám

egy a before row- delete, insert, update-ra.

Édesviz

 

Előzmény: NevemTeve (2383)
NevemTeve Creative Commons License 2007.06.28 0 0 2383
> Ha ennek a táblának a szerkezetét egy mezővel bővítjük, akkor elvileg az összes rá mutató hivatkozást is módosítani kell

Ez azért így, generikusan nem igaz, a következő esetekkel kell törődni:
1. SELECT *
2. INSERT, ha az új mező NOT NULL
3. Amikor az új mezőt adattal kell tölteni
Előzmény: Pathmaster (2382)
Pathmaster Creative Commons License 2007.06.28 0 0 2382
Default trigger

Adott egy olyan nagyméretű alkalmazás, amely gyakorlatilag csak részlegesen átlátható. Ez az alkalmazás egy olyan Oracle adatbázist használ, amelyben az egyik adattábláról nem lehet biztosan tudni azt, hogy az alkalmazás mely részeiről történik rá hivatkozás. Ez a hivatkozás lehet rekord beszúrás és módosítás is.

Ha ennek a táblának a szerkezetét egy mezővel bővítjük, akkor elvileg az összes rá mutató hivatkozást is módosítani kell; ami alól szerintem csak egy olyan trigger használata mentesíthet, amely az adattáblára hivatkozásokat figyeli, és szintaktikailag hibás hivatkozások paramétereit átadja egy szintaktikailag helyes hivatkozásnak és a hiányzó paramétereknek NULL értéket ad. Ez a trigger csak akkor adna vissza hibaüzenetet, ha egy olyan adat hiányzik, amelynek nem lehet NULL értéket adni.

Hogyan lehet ilyen triggert készíteni?
Előzmény: Pendragon (-)

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!