Keresés

Részletes keresés

208D Creative Commons License 2017.01.25 0 0 5595

Már golyózik a szemem a sok IF és ENDIF loop és egyebek között, de szépen haladok.

Ha nem fordul le, visszatérek az elöző, még működő mentéshez.

Előzmény: halaloszto (5594)
halaloszto Creative Commons License 2017.01.25 0 0 5594

próbáld ki, mit csinál az exceptionnel. doksi szerint true/false-t kell visszaadjon és kész. de értem hogy jó lenne üzenetet küldeni.

Előzmény: 208D (5593)
208D Creative Commons License 2017.01.25 0 0 5593

Vajk (Zs)!

 

Ok köszi. Műxik, de a függvényt még ki kell herélnem, hogy csak

-- Jelsző hossza nem lehet kevesebb mint 8
IF length(password) < 8 THEN
raise_application_error(-20002, 'A jelszó hossza kevesebb, mint 8 karakter');
END IF;

 

legyen benne, mert egyéb követelményektől megőrülünk.

Tudod, nem vagyok programozó, még ezzel eljátszom kicsit. Legalább nem 9, hanem csak 8 hosszú is lehet ezzel.

 

István, a Király

Előzmény: halaloszto (5592)
halaloszto Creative Commons License 2017.01.25 0 0 5592

https://oracle-base.com/articles/misc/basic-security-measures-for-oracle#password-verification-complexity

 

Ennél is egyszerűbb kell? Ez sem bonyi. Systemként csinálsz egy függvényt ami jóváhagy, és egy alter profileval beállítod a profilra.

 

Vajk

Előzmény: 208D (5591)
208D Creative Commons License 2017.01.25 0 0 5591

12-es oracle-ben hogyan tudom beállítani a legegyszerűbben, hogy egy adott profile-ba tartozó usernév jelszava min. 8 karakter legyen?

brioska Creative Commons License 2016.09.01 0 0 5590

Köszi a  válaszokat, utolsó jónak tűnik.

(Rajtam kívül álló okok miatt nem nagyon játszik a többi.)

 

---

 

Akkor is, ha ez szöggel kalapácsot :)

Előzmény: halaloszto (5589)
halaloszto Creative Commons License 2016.08.31 0 0 5589

synonym miért nem játszik? mindenképp meg akarod tartani a két külön táblát?

 

 - a táblák fölé csinálsz view-kat, és azokra instead of trigger?

 - oracle streams

 - goldengate

 - ágyúval verébre

 - az eredeti triggeredhez ugye kell update/insert/delete jogot adj a másik usernek a táblára. a triggerben meg tudod csekkolni hogy ki a current user, és ha az ellenfél, akkor nem írsz az ellenfél táblájába.

 

Vajk

 

Előzmény: brioska (5586)
NevemTeve Creative Commons License 2016.08.31 0 1 5588

Ne csináld. Inkább egy szöggel verjél be a falba pár kalapácsot.

Előzmény: brioska (5586)
brioska Creative Commons License 2016.08.31 0 0 5587

van-e arra mód, hogy pl BEFORE UPDATE-ban megkülönböztessem, hogy a másik AFTER UPDATE hívta-e, vagy szoftveres UPDATE volt?

Előzmény: brioska (5586)
brioska Creative Commons License 2016.08.31 -1 0 5586

Sziasztok, segítséget kérnék ismét :)

 

Adott egy DB, 2 DB user;

Egymástól függetlenül használt, azonos szoftver, ezekhez van user1, user2.

A 2 user-nél 1-1 tábla, tegyük fel, hogy a felépítése/ kiinduló adattartalma azonos a kettőnek.

Hogy lehet szinkronban tartani a kettőt a továbbiakban INSERT / UPDATE esetén úgy, hogy mindkét helyen vihetnek fel hozzá/ módosíthatnak az adatokon?

global_seq közös

SYNOYM nem játszik

Esetleges egyéb problémás táblakapcsolatoktól most tekintsünk el.

 

AFTER (műveletet hív a másik user táblájára) / BEFORE (megvizsgálja, van-e már ilyen rekord) TRIGGER-re gondoltam, ha megoldható.

De pl hogy lépjek ki BEFORE-ból, ha még sincsen szükség a műveletre (raise_application_error-t találtam, ennek van-e valami egyéb következménye)

Illetve UPDATE-nél hogy kerüljem el a végtelen oda-vissza hívást? (:NEW és :OLD hasonlítása elég, ha azonos, nem hívja a másikat?)

 

Egyéb ötletek/ javaslatok is jöhetnek, mik a buktatók esetleg.

Köszi

 

 

 

 

 

edesviz Creative Commons License 2016.08.16 0 0 5585

elvileg lelehetett tölteni oracle  db-t + sqldeveloper-t  és írhattattad a dolgokat. tesztelhetted. Fejlesztőnek nem kell érte fizetnie, csak megfelelően regisztrálni. A cégek is csak a produkciós adatbázisokért fizetnek. De azért keményen.

Előzmény: F1DO (5583)
NevemTeve Creative Commons License 2016.08.16 0 0 5584

Google nevű eszköz dobott egy ilyet: http://www.tutorialspoint.com/oracle_terminal_online.php

 

F1DO Creative Commons License 2016.08.16 0 0 5583

Sziasztok,

 

Egy gyors kérdés hátha tudtok segíteni:

 

Tárolt eljárás 'írásának' gyakorlására van valamilyen 'otthoni' mód?

(pl letölthető, vagy on-line elérhető adatbázis, illetve felület / környezet? )

halaloszto Creative Commons License 2016.08.03 0 0 5582

nem tudom mit akarsz, de olvasd el a dbms_metadata.get_ddl doksiját. tudsz vele create index statementet gyártatni a meglevő indexekből.

 

miért kell eldobni és újrakreálni? valamit meg kell változtatni rajta? szinte mindent lehet alter index-el is.

 

Vajk

Előzmény: stopposbácsi (5580)
mikkkro Creative Commons License 2016.08.03 0 0 5581

Persze, dinamikus sql-lel gyárthatsz hozzá scriptet.

Pl. egy adott séma indexeire vagy azon belül bizonyos betűvel kezdődő indexekre:

 

spool indexkukazo_script.sql

 

select 'drop index '||owner||'.'||index_name||';' from dba_indexes where owner='BELA' and index_name like 'DEMO_%';

 

 

spool off

 

 

A fejléc meg visszacsatolási sorokat utólag törölheted a scriptből, vagy előre beállítod setekkel, hogy ne is legyen. Aztán meg futtat indexkukazo_script.sql

Előzmény: stopposbácsi (5580)
stopposbácsi Creative Commons License 2016.08.03 0 0 5580

Lehetséges valahogy a dba_indexes táblából eldobni és megkreállni bizonyos indexeket? Hogy ne kelljen egyesével?

NevemTeve Creative Commons License 2016.07.21 0 0 5579

dblink-nél jött szembe egy probléma, amit nemnagyon látok megoldhatónak (illetve nagyobbacska beavatkozást igényel, ami bármilyen következménnyel is járhat, bár ez persze mindenre igaz, kezdve a számítógép bekapcsolásával).

 

Mondjuk én a LOCAL.LOC-NET adatbázisban vagyok, és DBLINK-et nyitok REMOTE.REMDOMAIN adatbázisra. Namostan tegyük fel, hogy a DBLINK neve rögzített (mert bele van heggesztve különféle nézetekbe/programokba), és abban a névben nincs .pont. Hanem mondjuk SZEMELYZETI_DBLINK. Tehát ilyesmit ténykedek:

 

create database link SZEMELYZETI_DBLINK
connect to HR identified by HR
using 'TNSNAMES-ENTRY';

Most jön az első jó hír: a DBLINK igazi neve SZEMELYZETI_DBLINK.LOC-NET lesz. Sebaj, azért egy-s-más működik (pl. SELECT COUNT(*) FROM DUAL@SZEMELYZETI_DBLINK)

 

Próbálunk valami bonyolultabbat, és jön a második jó hír: az Ora ránk pirít, hogy aljas módon beraktunk egy érvénytelen -hyphen jelet a névbe, és ez bizony szintaktikus hiba.

 

Google barátunk sok okos tanácshoz elvezet, a legtöbben azt mondják, hogy a távoli gép domain nevének van jelentősége. Hát nincs: valamilyen lelki okból a lokális domain-nevet csapja dblink nevéhez; kivéve, ha a névben eleve van egy vagy több .pont karakter.

 

További zsákutca: dblink-hez nem lehet szinonímát csinálni, csak a dblink-et át elért objektumhoz. (Tehát ha kétszáz kell, akkor nyilván kétszáz szinonímát csinálok, nem? Hát nem.)

 

Tehát csak két lehetőséget vélek látni:

1. nevezzük a dblink-et SZEMELYZETI.DBLINK-re

2. nevezzük át az adatbázist LOCAL.LOCNET-re

 

Ha egyik sem megy, akkor gondolkodóba esünk.

 

PS: ja és van egy global_names nevű session-paraméter, ami jobb, ha false, különben csak REMOTE.REMDOMAIN@VALAMI nevű dblink-et szeret a derék Ora a REMOTE.REMDOMAIN adatbázishoz. (Ez nagyon megkönnyítené a különféle migrációkat, élesítéseket, szolgáltatás-áthelyezéseket, az már biztos. (gyk: ez irónia volt))

brioska Creative Commons License 2016.07.18 0 0 5578

elejéről lemaradt, hogy a felhasználó nem tudja mit is szeretne :)

Előzmény: NevemTeve (5577)
NevemTeve Creative Commons License 2016.07.18 0 0 5577

Off: Most rock journalism is people who cannot write interviewing people who cannot talk for people who cannot read. (Frank Zappa)

 

Na ilyen az ámítástechnika is: a szervező nem tud szervezni, a programozó nem tud programozni, és persze ennek az eredményét a felhasználó sem tudja felhasználni.

F1DO Creative Commons License 2016.07.18 0 0 5576

Pontosan..

pl mindehhez elég ha van egy-két 'gazdag' fantáziával megáldott adatelemző/manager az ember munkahelyén, akik biztosítják, hogy részed legyen a változatos esetekben.

 

 

 

Előzmény: brioska (5575)
brioska Creative Commons License 2016.07.17 0 0 5575

Az élet irdatlan nagy marhaságokat tud produkálni.

 

De talán nem leszek megint közel 4 hónapig topic gyilkos :)

Előzmény: tanárnéni kedvence (5574)
tanárnéni kedvence Creative Commons License 2016.07.15 0 0 5574

Ne zavard már össze a topicot ilyen közel életszerű SQL utasításokkal! ;)

Előzmény: brioska (5570)
F1DO Creative Commons License 2016.07.15 0 0 5573

... tehát egyik helyen egy update-elendő oszlop az id, a másikon meg kulcs oszlop ( egy másik id oszloppal...)

Előzmény: F1DO (5572)
F1DO Creative Commons License 2016.07.15 0 0 5572

Igen, jogos a kérdés (csodálkoztam is hogy nincs erre rákérdezés) az eredeti feladatban id-t is updatelni kellett (a kulcsolás egy másik id-val történt) ezt rosszul adatam példába, elnézést.

Előzmény: brioska (5567)
F1DO Creative Commons License 2016.07.15 0 0 5571

Köszi, egy kis kiegészítés - pontosítás:

 

.. WHEN MATCHED THEN UPDATE SET ...

Előzmény: halaloszto (5563)
brioska Creative Commons License 2016.07.15 0 0 5570

na, szóval így gondoltam :)

 

UPDATE B SET adat = (SELECT MAX(A.adat) FROM A WHERE A.id = B.id)
WHERE EXISTS (SELECT 0 FROM A WHERE A.id = B.id AND A.adat IS NOT NULL);

Előzmény: halaloszto (5569)
halaloszto Creative Commons License 2016.07.15 0 0 5569

én is az övére írtam :-)

Előzmény: brioska (5567)
brioska Creative Commons License 2016.07.15 0 0 5568

úgy értem group by nélkül :)

Előzmény: brioska (5567)
brioska Creative Commons License 2016.07.15 0 0 5567

De külső tábla egyébként is beszűri arra az id-re, azon belül a MAX(adat) elég önmagában.

(F1DO írására vonatkozott a kérdés, nem a tiedre)

 

Előzmény: halaloszto (5566)
halaloszto Creative Commons License 2016.07.15 0 0 5566

a group by azért kell, hogy id-nként csak egy sorunk legyen. az azonos id-k egy group. a max(adat) a groupon belül a legnagyobb adatot adja vissza. a max(id) felesleges, hiszen a groupban csak egyféle id van. a distinct is felesleges, a group by miatt minden sorban más lesz az id.

 

Vajk

Előzmény: brioska (5565)

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