Új hozzászólás Aktív témák
-
-
Petya25
addikt
MS SQL-ben kellene a táblákat és megírt nézet/függvény/SP-kel kilistáznom hogy a készítés dátuma is rajta legyen?
Valami tipp?Táblákra van egy ilyenem:
SELECT SCHEMA_NAME(schema_id) AS schema_name, name AS table_name, create_date
FROM sys.tables
ORDER BY schema_name, table_nameAntonio Coimbra de la Coronilla y Azevedo, bizony!
-
disy68
aktív tag
válasz Petya25 #4802 üzenetére
A sys.objects-ben megtalálsz minden user által létrehozott objektumot. A sys.system_objects-ben a system által létrehozott és a sys.all_objects-ben pedig mindekettőt.
Ahogy a leírásban is benne van a különböző objektumok nevét megkaphatod az OBJECT_NAME függvény segítségével.Szűrsz a neked szükséges típusokra és meg is vagy.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
Micsurin
nagyúr
Rollback, commit, savepoint
miképp működik?Parancs alá írom vagy után mint egy új parancsot és együtt futtatom? Elolvastam a dokumentációt de most nem volt onnan világos a parancs működése.
Commit
gyakorlatilag mindenki számára láthatóvá teszi a változást pl egyUPDATE
esetén?The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
nyunyu
félisten
válasz Micsurin #4804 üzenetére
Egy tranzakcióban futó adatmanipulációs (DML) utasítások (insert, update, merge, delete...) hatását csak az őket futtató DB session látja, amíg a tranzakció nincs commitálva.
Mittudomén, van egy táblád, amiben van 10 rekord.
Nyitsz egy adatbáziskezelő ablakot, amiben kiadsz 5 insertet, meg 3 updateet, majd kiadsz egy select count(*) from tabla;-t, akkor az ott 15-öt fog mutatni.
Közben nyitsz egy másik ablakot, egy ott kiadott select * from tabla; az eredeti állapotot, 10 rekordot fog mutatni, a még nyitva lévő tranzakcióban hozzáadott ötöt, meg az updateek hatását nem!
Ha az első ablakban kiadsz egy commit;-ot (amivel véglegesíted az addig nyitott tranzakcióban futtatott DML utasítások hatását és lezárod a tranzakciót), akkor a második ablakbeli select *-ot újrafuttatva már 15, módosult rekord fog megjelenni.
Ha az első ablakban commit; helyett rollback;-et nyomsz, akkor teljesen eldobódik a nyitott tranzakcióban futtatott DMLek hatása, és visszaáll az eredeti állapotra.
Tehát ha utána kiadnál egy select *-ot, akkor ugyanazt a 10 eredeti rekordot látnád az első ablakban is, mint korábban a kettes ablakban.Adatdefiníciós (DDL) utasítások (pl. tábla létrehozás, eldobás, oszlop hozzáadás, index létrehozás...) mindig önálló tranzakcióban futnak és azonnal commitálódnak, így azok nem vonhatóak vissza kiadás után.
Meg ha jól rémlik, akkor az adott DB sessionben még függőben lévő tranzakciót is commitálják!Savepointokat még nem használtam, de ahogy olvasom arra jó, hogy rollbacknél meg lehessen mondani, hogy ne az egész addigi tranzakciót dobja el, hanem csak a savepoint után futtatott utasításokat.
Lehet, hogy valakik szerint ez jó ötlet, de alapvetően sérti a tranzakciók atomiságát, és jóval nehezebb egy félig lefutott tranzakció által elcseszett adatokat javítani, mint ha eldobnád az egészet a francba, és javítás után elölről újrafuttatnád az egészet.
Hello IT! Have you tried turning it off and on again?
-
-
nyunyu
félisten
MS SQL-nél begin tran-nal együtt kell futtatni az update-t, hogy rollback-elhető legyen.
Nem lehet az SSMS beállításainál kikapcsolni az autocommitot?
De, pirosat be kell pipálni, mert nem az a default:
Ezután nem fogja automatikusan commitálni a kiadott utasításokat.
Hello IT! Have you tried turning it off and on again?
-
Micsurin
nagyúr
Köszönöm! Életmentő volt holnap lesz csak órai téma de így végre letudom adni a félévest teljesen befejezve és nem kell már vele szórakozzak a héten, legalább ezzel kevesebb!
Keresgéltem de stackover után sem esett le teljesen a dolog pedig tényleg egyszerű...
Érdekes mindig ezekkel az egyszerűbb cuccokkal szenvedek, a tárolj eljárásos, függvényes triggeres téma valahogy jobban feküdt de sanszos, hogy a prog miatt.
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
tm5
tag
válasz Micsurin #4812 üzenetére
Még annyit érdemes tudni a többiek által leírtakon túl, hogy van egy TRUNCATE TABLE parancs, ami ugyanúgy kitöröl mindent egy táblából mint a DELETE parancs, csak DDL utasításként viselkedik, tehát azonnal végrehajtódik és nem is lehet rollback-elni. A DELETE-et a tranzakción belül még igen. Cserébe villámgyors. A DELETE az sok rekordra nagyon lassú tud lenni.
-
nyunyu
félisten
-
Micsurin
nagyúr
Köszönöm a válaszokat!
Még annyi kérdésem lenne( ), hogy ha adtam SESSION létrehozáshoz is jogos egy usernek, miért nem látja az adott séma tábláit?
Elméletileg pedig kéne lássa nem?CREATE ROLE raktáros IDENTIFIED BY r123;
CREATE ROLE eladó IDENTIFIED BY e123;
CREATE ROLE üzletvezető IDENTIFIED BY ü123;
CREATE USER Zolika IDENTIFIED BY z123;
GRANT UNLIMITED TABLESPACE TO Zolika;
CREATE USER Toma IDENTIFIED BY t123;
GRANT UNLIMITED TABLESPACE TO Toma;
CREATE USER Csilla IDENTIFIED BY c123;
GRANT UNLIMITED TABLESPACE TO Csilla;
GRANT CREATE SESSION TO Toma;
GRANT CREATE SESSION TO Csilla;
GRANT CREATE SESSION TO Zolika;
GRANT SELECT, INSERT, UPDATE, DELETE ON kereskedes TO eladó;
GRANT SELECT, INSERT, UPDATE, DELETE ON motorok TO eladó;
GRANT SELECT, INSERT, UPDATE, DELETE ON kiegeszitok TO eladó;
GRANT SELECT, INSERT, UPDATE, DELETE ON adasvetel TO eladó;
GRANT ALL PRIVILEGES TO raktáros;
GRANT SELECT ON kereskedes TO üzletvezető;
GRANT SELECT ON adasvetel TO üzletvezető;
GRANT SELECT ON motorok TO üzletvezető;
GRANT SELECT ON kiegeszitok TO üzletvezető;
GRANT SELECT ON maganszemely TO üzletvezető;
GRANT raktáros TO Zolika;
GRANT eladó TO Csilla;
GRANT üzletvezető TO Toma;
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
válasz Micsurin #4817 üzenetére
Ha jól értem most a táblák a hr user alatt "maradtak" mert ott hoztam létre ergo meg kell nevezzem a hr.-rel őket ha nem akarok ANY-vel teljes database wide jogot adni?
Így sem "léteznek" a tábláim.
[ Szerkesztve ]
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
nyunyu
félisten
válasz Micsurin #4818 üzenetére
GRANTolni csak az tud, akié a tábla, vagy kapott rá GRANTolási jogot, vagy DBA júzer.
Akinek csak olvasási/írási joga van, az nem tudja azokat továbbadni!Ha hr séma/júzer alatt hoztad létre a táblákat, akkor hr júzerrel kell kiadni a GRANTokat.
Utána a többi júzer select * from hr.táblanév;-vel fogja elérni őket.
Egyébként a táblák listája nyilvános, bárki lekérheti a select * from dba_tables;-t.
Ha a select * from all_tables;-t kérdezed, ott csak azokat mutatja az Oracle, amikhez az aktuális júzernek joga is van.[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Micsurin
nagyúr
hr alól lettek létrehozva a táblák és ott is lett a GRANT kiadva mivel megkötés volt, hogy ne lehessen jogot tovább adni.
De nem akarja az igazságot annyira nem, hogy disconnect majd connect ismét hr-rel átraktam mindent ANY-re, hát nem igazán hatotta meg a dolog mert továbbra sem léteznek a tábláim.
edit.: ezt a DBA-t mindjárt megnézem csak nulláztam a vmwaret inkább berakok minden kódot újra mert kezdtem kuszálni már.
[ Szerkesztve ]
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
select *
from dba_tables
where table_name='MOTOROK'; és végig próbálgatva is ORA-00942 lesz az az: a tábla vagy a nézet nem létezik.Pedig nulláról kezdtem:
Új kapcsolat Hr-be belépve, létrehoz és feltölt.
Kapcsolódtam a SYS as SYSDBA-ra megadtam az ALL PRIVILEGES-t a Hr-nek.
Létrehoztam a usereket és a role-okat, de semmi változás a dba_tables-re sem lehet lekérdezni.The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
...valamiért magától észhez tért nem tudom miért. Újraraktam a virtuális gépet most jó.
A sor szintű trigger az a
for each row
ugye?
Ha tábla szintű triggert írtak még nekünk ott a költő mire gondolt? statement trigger-re?The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
Köszönöm a sok segítséget az elmúlt hetekben, nagyon jól jött!
Első ZH-n anno megrántottak mert lehalt a vmware, na úgy néz ki nem ,hogy a bukás széléről kikapartam a tárgyat de 3-astól rosszabb nem igen lehetek már akkor se ha az elméleti ZH-t lenullázom.
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
nyunyu
félisten
válasz #29736192 #4827 üzenetére
Dokumentációja szerint a Postgre SIMILAR TO/NOT SIMILAR TO/~/~* operátoroknak egy patternt lehet megadni.
Úgyhogy nem úszod meg tárolt eljárás nélkül:
Kurzorba teszed a pattern lista tartalmát.
Végigiterálsz a kurzoron, minden egyes lépésnél egy ideiglenes táblába leválogatod az eredeti táblából az aktuális patternre illeszkedő értékeket.
Végén meg egy jól irányzott left joinnal kiválogatod az eredeti táblából azokat az értékeket, amik a másodikban NEM szerepelnek.Hello IT! Have you tried turning it off and on again?
-
válasz #29736192 #4827 üzenetére
természetesen tud.
azért arra készülj fel lélekben, hogyha csinálsz egy nagyobbacska táblára full joint egy párszáz regexpes táblával, attól szédülni fog a cucc
át.select keresendo from keresendotabla,regexptabla where keresendo ~ regexposzlop;
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
nyunyu
félisten
válasz #29736192 #4832 üzenetére
Jó lesz az, csak halmazokban kéne gondolkozni.
Neked a regexp kifejezések uniójának negáltja kell, nem a negált regexpek uniója!Vagyis left join on keresendo ~ regexp... where regexp is null.
bambano megoldását szabvány join szintaxisra átírva:
select keresendo
from keresendotabla
left join regexptabla
on keresendo ~ regexposzlop
where regexposzlop is null;[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
válasz #29736192 #4830 üzenetére
mindig jó ötlet az adatbáziskezelőn belül tartani a melót.
tehát ha meg tudod úgy oldani a programot, hogy ne kelljen kihúzgálni az adatot az sql szerverből, akkor az jobb.ezzel szemben van az, hogy jelen esetben is elszállhat a memóriaigény.
legegyszerűbb kipróbálni és megmérni a lehetséges verziókat.
nálad probléma lehet, hogy ebben a megoldásban a regexp rámegy azokra a sorokra is, amiket egy korábbi regexp már kizárt, ami elég nagy pazarlás. tehát ha külső nyelvből csinálnád a keresést, akkor lehet, hogy egyszerűbb lenne úgy, hogy csinálsz egy temporális táblát, abba belerakod az összes adat azonosítóját, amit az első regexppel szűrtél és még kell, majd utána a többivel sorban kiszórod belőle azt, ami nem kell. ha a regexpeket gyakoriság szerinti csökkenő sorrendben teszteled, akkor az hatékonyabb lesz.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
nyunyu
félisten
válasz bambano #4835 üzenetére
Ezzel viszont vissza is kanyarodtunk a kurzoron végigiterálós megoldáshoz, amit macerásabb megírni, mint az előbbi jólfésült selectet
nagy vonalakban valami ilyesmi:
declare
cursor c is
select regexp
from regexptabla
order by gyakorisag desc;
r varchar2(100);
begin
truncate temptabla;
open c
loop
fetch c into r;
exit when c%NOTFOUND;
insert into temptabla (voltmar)
select e.ertek
from eredetitabla e
left join temptabla t
on e.ertek = t.voltmar
where t.voltmar is null
and e.ertek ~ r;
end loop;
close c;
select e.ertek
from eredetitabla e
left join temptabla t
on e.ertek = t.voltmar
where t.voltmar is null;
end;(Nem vágom a postgre szintaxisát.)
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz #29736192 #4834 üzenetére
Unió az VAGYlagos kapcsolatot jelent, ÉS meg metszetet.
Neked az kell, hogy egyik regexpnek sem felel meg, azaz -regexp1 ÉS - regexp2 ÉS -regexp3... (komplementerek/negáltak metszete!)
Ezt ha levezeted, akkor azzal egyenlő, hogy -(regexp1 VAGY regexp2 VAGY regexp3...) (unió komplementere/negáltja!)Mivel a táblák sorai között mindig VAGYlagos kapcsolat van (tábla a sorainak uniója!), így ez utóbbi azt jelenti, hogy az érték nincs a regexp tábládban.
A táblából meg úgy kapjuk meg a B-ben nem szereplő értékeket, hogy LEFT JOIN ... IS NULL.[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Louro
őstag
Sziasztok!
Bár ritkán adom fel, de ez most kifogott rajtam és a Google se segített.
Alap: SQL Server
Minta:CREATE TABLE t1 AS (
id int,
name varchar,
dependency int
);
INSERT INTO t1 VALUES (1,'n1',0);
INSERT INTO t1 VALUES (2,'n2',1);
INSERT INTO t1 VALUES (3,'n3',1);
INSERT INTO t1 VALUES (4,'n4',2);
INSERT INTO t1 VALUES (5,'n5',3);
INSERT INTO t1 VALUES (6,'n6',3);
SELECT DISTINCT ca.id
FROM t1
LEFT JOIN t1 AS t2 ON t2.ID = t1.dependency
LEFT JOIN t1 AS t3 ON t3.ID = t2.dependency
CROSS APPLY (
SELECT t1.ID UNION ALL
SELECT t2.ID UNION ALL
SELECT t3.ID ) AS c (id);
A nagy kérdés, hogy én komfortosabb vagyok a JOIN-okkal, mint az APPLY-okkal. Ezt bevallom értelmezni se tudom. Az megvan, hogy egy hierarchiát épít, de a CROSS APPLY esetén a (id) kicsit fura, mert melyik ID-val köti össze a CROSS APPLY-ban lévő ID-t? Vagy duplikálna? A kód szerzője ismeretlen
Valami ilyesmi lenne?
SELECT DISTINCT ca.id
FROM t1
LEFT JOIN t1 AS t2 ON t2.ID = t1.dependency
LEFT JOIN t1 AS t3 ON t3.ID = t2.dependency
LEFT JOIN (
SELECT t1.ID UNION ALL
SELECT t2.ID UNION ALL
SELECT t3.ID ) AS c ON t1.ID = c.ID OR t2.ID = c.ID OR t3.ID;
[ Szerkesztve ]
Mess with the best / Die like the rest
-
tm5
tag
Amúgy csak megérteni szeretnéd, vagy átírni?
(Kis csiszolgatás után) beraktam beraktam sqlfiddle-be a mintádat, de nem sok értelmeset produkált: (null),1,...6-ig hozta az összes ID-t
Ha esetleg szeretnél hierarchiát építeni SQL Serverben arra ott a rekurzív CTE
-
Kommy
veterán
Szeretném megcsinálni azt, hogy vannak partnereink akik sajnos valami folytán kétszer kerültek be az adatbázisunkba és szeretném a kölcsönzéseiket összevonni az újabb regisztrációba.
Név és telefonszám alapján le is tudom kérdezni a listát ahol látom az összes duplikációt.
A lényeg az lenne, hogy a régebbi partnerhez tartozó kölcsönzéseket átrakjam az új partnerre.
A kölcsönzések tábla tartalmazza természetesen a partnerid-t, így ott kellene valahogy kicserélnem a régi az újra.Itt e lekérdezés a duplikációkra itt szépen látom az id-t, a nevet és a telefonszámot.
SELECT
y.id,y.nev, y.Kapcsolat
FROM Partnerek y
INNER JOIN (SELECT
nev, kapcsolat, COUNT(*) AS CountOf
FROM Partnerek
GROUP BY nev, Kapcsolat
HAVING COUNT(*)>1
) dt ON y.kapcsolat=dt.kapcsolat order by Kapcsolat
[kép] -
DS39
nagyúr
jó az irány.
még group by-old a külső select-et névre és telefonszámra, és az id-t MIN()-eld.
ezt mentsd el egy temp táblába, majd a temp táblához join-old be a partner táblát, név és telefonszám alapján + temp.ID <> partner.ID
így meglesz egy rekordban a duplikált partner régi és új id-ja, ezzel már könnyen meg tudod írni az update-t, hogy a kölcsönzés táblában mit mire kell cserélni.
+ én még a partner táblát bővíteném egy oszloppal, hogy törölt / archív, és a régi id-ek megjelölném, így később ki lehet őket szűrni.