Keresés

>>>>>>>>>>
igen, lehetne, de nekem nem tűnik átláthatónak, ha egy táblában vannak az sql-ek ha pl: javítani kell valamit több sqlben is, vagy hibakereséskor. persze ez szokás kérdése is.
>>>>>>>>>>

Naigen... :o) Ezért képezheti megfontolás tárgyát kimenni vele a file-rendszerbe.
És erről (is) beszéltem többtíz hozzászólással korábban a repository-témánál. Persze izlések és pofonok különböznek, ahogy elismertem akkor is.

Kicsiben olyan a dolog, mintha valaki VI-jal fejleszt Oracle alá store procedure-ket és triggereket. Láttam ilyet (még kezdőként annó, azóta hálistennek sose), nagyon gyorsan és profin ment, csak azon izgultam, hogy ne nekem kelljen majd a gányhegyben hibát vadásznom, annyira átláthatatlan lett a forrás.. Persze a zseni az, aki uralja a káoszt, mint tudjuk. :o))))

>"tárolt eljárásba 'beégetett' dinamikus sql-ek"
>így leírva kicsit falsul is cseng, tényleg :)

Én arra gondoltam: ahogy szó is volt már róla, execute immediate-t megfontoltan használ az ember. Nem performancia okból, hanem mert például fordítási időben nem derülnek ki az sql-ek szintaktikai hibái, pl.: string literálok miatt erősen kell tornászni, és nem olyan trivi oda-vissza konvertálni dinamikusból statikusba az sql-eket. És ahogy te is mondtad, az átláthatóságot is erősen tudja rongálni.

>nekem is, de pl/sql tárolt eljárásaink vannak, így sajnos a cikkben leírt megoldást nem tudom használni.

Nem látom be, miért ne tudnád. Valóban sql*plus-os a demó, anonym plsql blokkokkal, de ez nem azt jelenti, hogy csak ott tudod használni, hanem ez az a legkisebb közös nevező, ami minden Oracle-t használó ember egyformán el tud érni. (Még ha nem is akarja... ;)

igen, lehetne, de
nekem nem tűnik átláthatónak,
ha egy táblában vannak az sql-ek
ha pl: javítani kell valamit több sqlben is,
vagy hibakereséskor.
persze ez szokás kérdése is.

dz

"Nekem tetszik a orafaq-os cikkben emlegetet 10gr2-s ficsőr is."
nekem is, de pl/sql tárolt eljárásaink vannak, így sajnos
a cikkben leírt megoldást nem tudom használni.

"tárolt eljárásba 'beégetett' dinamikus sql-ek"
így leírva kicsit falsul is cseng, tényleg :)

dz

Nekem volt ilyesmihez keretrendszerem; és annó én könnyebbnek találtam kereshetőség/átláthatóság és szerkeszthetőség szempontjából a file-rendszerbeli sql-file-okat, mint az adatbázis clob-os sql-eket. Így paramétertől függően felolvastam db-be, vagy egyből db-ből futtattam (változatlanság esetén) az ilyen sql-eket.

Nekem tetszik a orafaq-os cikkben emlegetet 10gr2-s ficsőr is.

Hacsak nem numerikus adatok insertjéről van szó én kerülném a tárolt eljárásba 'beégetett' dinamikus sql-ek bármilyen formáját is.

Szia,
ha már paraméterkent is hívhatnád az sql-eket, akkor akár a db-ben is tárolhatnád.
Édesviz

persze nem jolly-joker, nem mindenhol használható resume next
de sok esetben igen jól tudna jönni...

Azert eletszerubb (bar nem biztos, hogy a legpraktikusabb) szvsz a Begin-End blokk mint egy ilyen Resume Next utasitas, mert mi van akkor, ha a nagytomegu utasitasok nem hajthatoak kulon-kulon is vegre, hanem mondjuk van egy insert egy apa tablaba es utan a3 insert egy fiu tablaba. Ebben az esetben csak egy blokkent kezelhetoek, hiszen az apa insert hibaja utan nem lehet a fiu inserteket vegrehajtani, hanem a kovetkezo blokkon lehet csak folytatni.

ok. jövő héten kipróbálom ezt a verziót is.
köszönöm a segítséget.
(halkan:
nem értem miért nincs ilyen utasítás (pl: resume next) beépítve,
kizárt hogy csak nekem van ilyen gondom...)
(de az is lehet, csak én érzem triviálisnak)

dz

Szvsz file-kent, nem kell feleslegesen bonyolitani :-)

és a létrehozandó szkripteket szkriptben tárolnád,
vagy egy táblában?

Az alap script minden modositasa utan le kell futtatni a vegleges sql-t gyarto scriptet. Ha a hibakezelesbe kell belenyulni, akkor csak az SQL-t gyarto scriptet kell modositani, es igy legalabb garantalhato, hogy minden utasitasnal megfelelo lesz az exception. Akar egy pre-compiler-kent is felfoghatod :-)

igen igen lehetne,
de még a fejlesztés elején vagyunk, ezért sok belenyúlás lesz
a hibakezelésbe.
Akkor meg minden egyes hibakezelést külön kell majd módosítani.
Ha meg a script gyártó scriptet módosítgatom, akkor
az nem lesz elég olvasható sajnos
de az ötlet jó
(ha jól értettelek)

dz

Es egy egyszeru konvertalo script, ami a nyers sql-eket tartalmazo file-t a kivant formara hozza?

igen az adatbázis építés kezdeti részén mi is sok triggert, seq-et consr. indexet és sok egyebet generáltunk. Nekem nem az a gondom,
hogy mindenhova egyszer felvegyem a begin blokkokat,
hibakezelést.
Csak majd ha módosítani kell a hibakezelést akkor
megint 100+ helyre kell benyúlni, hogy átvezessem az új dolgokat.

Igaz hogy paraméterként is hívhatnám az sqleket, de az
szerintem az átláthatóságot erősen rontaná.

dz

Szia,
az utasításaidtól függ,
de "100" utasítást is teheted egy proci paraméterének, igy van "100" hivásod és egy procid egy begin end blokkal. Azért volt olyan szitu már az életemben, amikor kollégával awk-val generáltunk PL/Sql packegeket-triggereket, táblaszámra.
Édesviz

Köszönöm mindenkinek a segítséget.
ezek szerint marad a sok begin blokk...
dz

sehogy.

A WHENEVER egy sqlplus utasítás, semmi köze a PL/SQL nyelvhez.
Ha ilyesmiket akarsz, lehet hogy jobban járnál
a) egy sqlplus-al futtatott
b) valami már külső programmal futtatott
SQL utasítások sorozatával...

köszönöm megnézem.
a WHENEVER SQLERROR CONTINUE nem látom még hogy
job által hívott tárolt eljárásnál
hogyan tudnám használni?

dz

"néhány száz insert, merge" egy tárolt eljárásban???
na mindegy, azért leírom, ami nekem eszembe jutott:
az egyik hogy ha lehetőséged van rá, akkor error_logba íratod a hibát:
egy leírás itt: http://orafaq.com/node/76
vagy
(bár itt tárolt eljárásról van szó) az SQL script esetén van egy
WHENEVER SQLERROR CONTINUE, csak itt logba (spool) tudod iratni a hibát, de a futás megy tovább...

Esetleg használj egy preprocesszort, amilyen a cpp:

#define ProtExec (dml)
BEGIN
dml;
EXCEPTION WHEN OTHERS END;

ProtExec (INSERT...)
ProtExec (DELETE...)

Köszönöm,

igen igaz, jók a begin blokkok
de néhány száz insert, merge esetében
egyenként beletenni a
begin
<sql>
... EXCEPTION
... end
blokkokat
az nem tűnik elegánsnak
Nincs valami olyan dolog
pl mint a resume next
vagy esetleg hibakezeléskor
a hibás sor számát megkapni
és oda hibakezelés után vissza menni
vagy a következővel folytatni?

dz

így jár az, aki nem nyomkod állandóan frissítést...

Ilyenkor a sql utasítások köré kis beágyazott BEGIN-blokkot szoktam tenni, saját EXCEPTION-résszel. Az nem jó?

Szia,

tedd az utasitást, begin end blokkba, és hasznélj exception-t.

Édesviz

végtelenül elegáns a megoldás:

begin
 insert
exception when others then ...
 
end;

begin
...

Sziasztok!

Lenne egy kérdésem:
Hibakezelés után szeretném a következő sorral
folytatni a tárolt eljárás végrehajtását.
Pl ha sok insert, merge -t tartalmazó
tárolt eljárás valamelyik sql-je
hibát okoz a hibaüzenetet el tudjam tenni egy táblába,
de ne álljon meg a végrehajtás
hanem menjen a következő sql utasításra.
(MS Accessben volt ilyen "resume next" néven)

(cimkéket goto-t nem igazán szeretnék használni.
loop blokkokba tenni is problémás lenne.)

Tud valaki valami elegánsabb megoldást?

Köszönöm:
dz.

Ez nem mindig megy. Nekem VPN-en keresztül lehal a csatorna, ha sokáig nincs mozgás, így az eljárás is lehal, ha hosszan fut. Ezért én is dzsobozok.

A dbms_job-nak van még egy nagyon kellemes lehetősége, a 'mesterséges' párhuzamosítás. Egy alapvetően nem párhuzamosított tárolt eljárás esetén, ha lehetséges "diszjunktosítani" a futást, akkor több példánya is indulhat a tárolt eljárásnak. Rengetegszer működni tudó hasznos dolog, adott esetben meglepően jó performanciával, legalábbis saját tapasztalataim szerint.