Wybieranie danych z user lub all synonyms
colin - 29-11-2005 10:12
Wybieranie danych z user lub all synonyms
Witam
Ostatnio napotkałem drobny problem. Mianowicie:
1) Utworzyłem procedurę w schemacie A, która posiada w swojej treści
zapytanie:
SELECT TABLE_OWNER||'.'||TABLE_NAME
INTO v_user_tree
FROM ALL_SYNONYMS
WHERE SYNONYM_NAME = 'TREE'
AND OWNER = 'ZP';
2) Utworzyłem użytkownika ZP, utworzyłem dla niego synonim TREE do obiektu w
innym schemacie. Użytkownikiem ZP wywołuję procedurę z p. 1. Spodziewałem
się uzyskać odpowiedź: nazwa_schematu.nazwa_obiektu do którego odnosi się
synonim, jednak mimo wszystko otrzymuję ciąg pusty.
3) Podczas testów spotkałem się z kilkoma dziwnymi kwiatkami:
- kiedy ubrałem zapytanie w blok:
BEGIN
SELECT TABLE_OWNER||'.'||TABLE_NAME
INTO v_user_tree
FROM ALL_SYNONYMS
WHERE SYNONYM_NAME = 'TREE'
AND OWNER = 'ZP';
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('BLAD ODCZYTU Z LISTY SYNKOW');
END;
uzyskałem błąd zgłoszony przez obsługę tego wyjątku podczas wywoływania
funkcji jako użytkownik ZP poleceniem:
select A.nazwa_funkcji from dual;
Natomiast przy wykonaniu powyższego zapytania bez tego typu bloku BEGIN/END
zapytanie po prostu przerywa działanie funkcji bez wykonywania dalszych
poleceń, bez zgłaszania jakichkolwiek błędów.
Pytanie więc brzmi: dlaczego jako użytkownik z poza schematu A zapytanie z
p.1 nie zwraca danych?
PS: jak w nazwie tematu identyczne zachowanie cechuje zapytanie do
USER_SYNONYMS.
pozdrawiam i czekam na komentarze, a najlepiej przyczynę takiego zachowania,
ew. sugestie w jaki sposób można wyłuskać te dane inną drogą
colin
colin - 01-12-2005 20:33
Udało mi się rozwiązać problem w najbardziej nieodpowiedni sposób -
przywilej SELECT ANY TABLE dla schematu A pozwala na wybieranie danych z
poziomu procedury i zwraca dobry wynik. Jednakże tego typu uprawnienie jest
zbyt mocne. Grant'y różnego rodzaju na ALL_SYNONYMS dla schematu A nie dają
rezultatu, nawet grant'y na składowe elementy tego widoku.
=?ISO-8859-2?Q?S=B3awomir_Szysz=B3o?= - 01-12-2005 20:33
Dnia Tue, 29 Nov 2005 10:15:30 +0100, "colin" <sscolinss@poczta.onet.pl>
wklepał(-a):
>Witam
>
> Ostatnio napotkałem drobny problem. Mianowicie:
.... nie napisałeś o jaką bazę chodzi. Ale domyślam się, że Oracle.
>1) Utworzyłem procedurę w schemacie A, która posiada w swojej treści
>zapytanie:
>
> SELECT TABLE_OWNER||'.'||TABLE_NAME
> INTO v_user_tree
> FROM ALL_SYNONYMS
> WHERE SYNONYM_NAME = 'TREE'
> AND OWNER = 'ZP';
Unikaj konstrukcji SELECT INTO - bezpieczniej jest zrobić kursor - unikniesz
błędów "Jednowierszowe zapytanie zwraca więcej niż jeden wiersz".
>2) Utworzyłem użytkownika ZP, utworzyłem dla niego synonim TREE do obiektu w
>innym schemacie. Użytkownikiem ZP wywołuję procedurę z p. 1. Spodziewałem
>się uzyskać odpowiedź: nazwa_schematu.nazwa_obiektu do którego odnosi się
>synonim, jednak mimo wszystko otrzymuję ciąg pusty.
Jako jaki użytkownik tworzyłeś synonim? Co pokazuje zapytanie:
SELECT SYNONYM_NAME, OWNER
FROM ALL_SYNONYMS
WHERE SYNONYM_NAME='TREE';
>3) Podczas testów spotkałem się z kilkoma dziwnymi kwiatkami:
>
>- kiedy ubrałem zapytanie w blok:
>
> BEGIN
>
> SELECT TABLE_OWNER||'.'||TABLE_NAME
> INTO v_user_tree
> FROM ALL_SYNONYMS
> WHERE SYNONYM_NAME = 'TREE'
> AND OWNER = 'ZP';
>
> EXCEPTION
> WHEN OTHERS THEN
> DBMS_OUTPUT.PUT_LINE('BLAD ODCZYTU Z LISTY SYNKOW');
> END;
>
>
>uzyskałem błąd zgłoszony przez obsługę tego wyjątku podczas wywoływania
>funkcji jako użytkownik ZP poleceniem:
>
>select A.nazwa_funkcji from dual;
Usuń obsługę wyjątku i podaj numer komunikatu błędu.
>Natomiast przy wykonaniu powyższego zapytania bez tego typu bloku BEGIN/END
>zapytanie po prostu przerywa działanie funkcji bez wykonywania dalszych
>poleceń, bez zgłaszania jakichkolwiek błędów.
>
>Pytanie więc brzmi: dlaczego jako użytkownik z poza schematu A zapytanie z
>p.1 nie zwraca danych?
Zapewne utworzyłeś synonim jako użytkownik A, więc on jest jego właścicielem.
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych
colin - 01-12-2005 20:33
Użytkownik "Sławomir Szyszło" <slaszysz@poczta.onet.pl> napisał w wiadomości
news:dmikrv.1cg.1@slaszysz.poczta.onet.pl...
> Dnia Tue, 29 Nov 2005 10:15:30 +0100, "colin" <sscolinss@poczta.onet.pl>
> wklepał(-a):
>
> >Witam
> >
> > Ostatnio napotkałem drobny problem. Mianowicie:
>
> ... nie napisałeś o jaką bazę chodzi. Ale domyślam się, że Oracle.
// faktycznie, zapomniałem całkiem - jednakże dobrze się domyśliłeś
>
> >1) Utworzyłem procedurę w schemacie A, która posiada w swojej treści
> >zapytanie:
> >
> > SELECT TABLE_OWNER||'.'||TABLE_NAME
> > INTO v_user_tree
> > FROM ALL_SYNONYMS
> > WHERE SYNONYM_NAME = 'TREE'
> > AND OWNER = 'ZP';
>
> Unikaj konstrukcji SELECT INTO - bezpieczniej jest zrobić kursor -
unikniesz
> błędów "Jednowierszowe zapytanie zwraca więcej niż jeden wiersz".
Jak wiele synonimów o nazwie 'TREE' może posiadać użytkownik 'ZP' ? Szerzej,
jak wiele obiektów o nazwie 'TREE' może posiadać użytkownik 'ZP'?
(oczywiście mówimy o Oracle'u) - ale faktycznie, kursor byłby skuteczniejszy
jeżeli nie ma się zamiaru wykonywać bloku z obsługą wyjątków. W tym wypadku
mogę jedynie obawiać się błędu NO_DATA_FOUND, który najczęściej obsługuję
jako zdefiniowany wyjątek na końcu bloku programu.
>
> >2) Utworzyłem użytkownika ZP, utworzyłem dla niego synonim TREE do
obiektu w
> >innym schemacie. Użytkownikiem ZP wywołuję procedurę z p. 1. Spodziewałem
> >się uzyskać odpowiedź: nazwa_schematu.nazwa_obiektu do którego odnosi się
> >synonim, jednak mimo wszystko otrzymuję ciąg pusty.
>
> Jako jaki użytkownik tworzyłeś synonim? Co pokazuje zapytanie:
> SELECT SYNONYM_NAME, OWNER
> FROM ALL_SYNONYMS
> WHERE SYNONYM_NAME='TREE';
Synonim założyłem z poziomu użytkownika A, zapytanie w powyższej formie (bez
dodatkowego ograniczenia nazwy właściciela) zwraca wszystkie synonimy o
nazwie 'TREE' z wszystkich schematów, do których użytkownik ma dostęp, m.
in. wymieniona jest krotka z informacją o synonimie użytkownika ZP do
obiektu w schemacie A (czyli interesujący mnie obiekt).
>
> >3) Podczas testów spotkałem się z kilkoma dziwnymi kwiatkami:
> >
> >- kiedy ubrałem zapytanie w blok:
> >
> > BEGIN
> >
> > SELECT TABLE_OWNER||'.'||TABLE_NAME
> > INTO v_user_tree
> > FROM ALL_SYNONYMS
> > WHERE SYNONYM_NAME = 'TREE'
> > AND OWNER = 'ZP';
> >
> > EXCEPTION
> > WHEN OTHERS THEN
> > DBMS_OUTPUT.PUT_LINE('BLAD ODCZYTU Z LISTY SYNKOW');
> > END;
> >
> >
> >uzyskałem błąd zgłoszony przez obsługę tego wyjątku podczas wywoływania
> >funkcji jako użytkownik ZP poleceniem:
> >
> >select A.nazwa_funkcji from dual;
>
> Usuń obsługę wyjątku i podaj numer komunikatu błędu.
Jak zaznaczyłem dwie linie poniżej... bez bloku danych i obsługi błędu nie
występuje żaden komunikat o błędzie a fakt, że po tym zapytaniu przerywane
jest działanie funkcji namierzyłem jedynie poprzez wstawienie
DBMS_OUTPUT.PUT_LINE i odnotowaniu, w którym momencie oracle przestał
wysyłać komunikaty. I to właśnie ten 'kwiatek', na który chciałem zwrócić
uwagę.
>
> >Natomiast przy wykonaniu powyższego zapytania bez tego typu bloku
BEGIN/END
> >zapytanie po prostu przerywa działanie funkcji bez wykonywania dalszych
> >poleceń, bez zgłaszania jakichkolwiek błędów.
> >
> >Pytanie więc brzmi: dlaczego jako użytkownik z poza schematu A zapytanie
z
> >p.1 nie zwraca danych?
>
> Zapewne utworzyłeś synonim jako użytkownik A, więc on jest jego
właścicielem.
Polecenie:
CREATE SYNONYM ZP.ABC FOR A.MOJA_TABLICA;
wykonane z poziomu schematu A powoduje utworzenie synonimu w schemacie ZP.
Dalej zadając zapytanie z poziomu użytkownika ZP:
SELECT * FROM ALL_SYNONYMS WHERE OWNER = 'ZP'
możemy zauważyć, że to użytkownik ZP jest właścicielem synonimu więc nie
wiem, co właściwie ma to stwierdzenie do reszty sprawy (pomijając nawet
fakt, że jest nieprawdziwe).
PS: właściwie rozwiązałem problem w inny sposób, jednakże "kwiatek", który
opisałem nadal nie daje mi spokoju. Wygląda to na jakąś lukę w Oraclu, gdyż
nie zgłaszanie błędu chyba do tego typu zagadnień można zaliczyć.
pozdrawiam
colin
=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 01-12-2005 20:33
Sławomir Szyszło wrote:
>>1) Utworzyłem procedurę w schemacie A, która posiada w swojej treści
>>zapytanie:
>>
>> SELECT TABLE_OWNER||'.'||TABLE_NAME
>> INTO v_user_tree
>> FROM ALL_SYNONYMS
>> WHERE SYNONYM_NAME = 'TREE'
>> AND OWNER = 'ZP';
>
>
> Unikaj konstrukcji SELECT INTO - bezpieczniej jest zrobić kursor - unikniesz
> błędów "Jednowierszowe zapytanie zwraca więcej niż jeden wiersz".
Jaki to ma sens. Jeśli spodziewam się, że zapytanie zwróci jeden wiersz, to ma
zwrócić jaden. Jeśli zwraca więcej, to to jest sytuacja wyjątkowa i powinien być
zgłoszony wyjątek.
--
P.M.
Lucyna Witkowska - 01-12-2005 20:34
colin <sscolinss@poczta.onet.pl> napisał:
> PS: właściwie rozwiązałem problem w inny sposób, jednakże "kwiatek", który
> opisałem nadal nie daje mi spokoju. Wygląda to na jakąś lukę w Oraclu, gdyż
> nie zgłaszanie błędu chyba do tego typu zagadnień można zaliczyć.
Mysle, ze nie jest luka w Oracle tylko swiadome dzialanie.
W tym przypadku chcesz ogladac A.all_synonyms przez uzytkownika ZP
za posrednictwem funkcji.
Gdyby cos takiego bylo mozliwe, to
Oracle musialby wybierac dla ZP tylko te synonimy, ktore odnosza sie do tabel,
ktore ZP może zobaczyc - co z kolei powodowaloby rozny obraz
A.all_synonyms dla A i ZP.
Dlatego dopiero nadanie grantu SELECT ANY TABLE "poprawilo" dzialanie, ale
nadmiernie zwiekszylo uprawnienia ZP.
Pozdrowienia,
LW
=?ISO-8859-2?Q?S=B3awomir_Szysz=B3o?= - 01-12-2005 20:34
Dnia Wed, 30 Nov 2005 09:29:19 +0100, "colin" <sscolinss@poczta.onet.pl>
wklepał(-a):
>Synonim założyłem z poziomu użytkownika A, zapytanie w powyższej formie (bez
>dodatkowego ograniczenia nazwy właściciela) zwraca wszystkie synonimy o
>nazwie 'TREE' z wszystkich schematów, do których użytkownik ma dostęp, m.
>in. wymieniona jest krotka z informacją o synonimie użytkownika ZP do
>obiektu w schemacie A (czyli interesujący mnie obiekt).
OK.
>Jak zaznaczyłem dwie linie poniżej... bez bloku danych i obsługi błędu nie
>występuje żaden komunikat o błędzie a fakt, że po tym zapytaniu przerywane
>jest działanie funkcji namierzyłem jedynie poprzez wstawienie
>DBMS_OUTPUT.PUT_LINE i odnotowaniu, w którym momencie oracle przestał
>wysyłać komunikaty. I to właśnie ten 'kwiatek', na który chciałem zwrócić
>uwagę.
Po pierwsze - usuń blok EXCEPTION to dowiesz się, jaki naprawdę błąd występuje.
Po drugie - pokaż może pełen kod tych obu wersji procedur, bo inaczej do niczego
nie dojdziemy.
A poniżej moje testy:
User A:
create or replace function synek return varchar2 as
v_user_tree varchar2(100);
begin
SELECT TABLE_OWNER||'.'||TABLE_NAME
INTO v_user_tree
FROM ALL_SYNONYMS
WHERE SYNONYM_NAME = 'TREE'
AND OWNER = 'SCOTT';
return v_user_tree;
end;
SELECT A.SYNEK FROM DUAL;
(null)
User A as sysdba (żeby utworzyć synonim w schemacie scott):
CREATE SYNONYM scott.TREE FOR A.domeny;
SELECT A.SYNEK FROM DUAL;
A.DOMENY
User SCOTT:
SELECT A.SYNEK FROM DUAL;
ORA-00904 Niepoprawny identyfikator ...
User A:
grant execute on synek to scott;
User SCOTT:
SELECT A.SYNEK FROM DUAL;
A.DOMENY
Dziwne, u mnie działa. :)
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych
=?ISO-8859-2?Q?S=B3awomir_Szysz=B3o?= - 01-12-2005 20:34
Dnia Wed, 30 Nov 2005 14:27:51 +0100, Paweł Matejski
<madej@spam.madej.pl.eu.org> wklepał(-a):
>Jaki to ma sens. Jeśli spodziewam się, że zapytanie zwróci jeden wiersz, to ma
>zwrócić jaden. Jeśli zwraca więcej, to to jest sytuacja wyjątkowa i powinien być
>zgłoszony wyjątek.
W pewnych przypadkach lepiej jest obsługiwać wartość null zwróconą z kursora
zamiast wyjątku.
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[MSSQL2000] Problem z =?ISO-8859-2?Q?tabel=B1/indeksem/zapytanie?==?ISO-8859-2?Q?m_czy_b=B3=B1d_w_bazie_danych=2E=2E=2E?=
=?iso-8859-2?Q?=5BMySQL=5D_Wy=B6wietlenie_wszystkich_rekordow _zawierajacy?==?iso-8859-2?Q?ch_duplikat_a__moze_inna_struktura_bazy_danych ?=
Konwesja znaków w dump'ie bazy danych - ISO -> utf-8 -> ISO -> utf-8
[laik]Jak =?ISO-8859-2?Q?stworzy=E6/zaczac_tworzyc__ma=B3=B1?==?ISO-8859-2?Q?__baz=EA_danych_na_potrzeby_www=3F?=
[mysql] przenoszenie danych =?ISO-8859-2?Q?mi=EAdzy_tabelami_?==?ISO-8859-2?Q?w_r=F3=BFnych_bazach?=
Ksiazka - "Podstawowy =?ISO-8859-2?Q?wyk=B3ad_z_system=F3w_?==?ISO-8859-2?Q?baz_danych=22?=
Zrywanie =?ISO-8859-2?Q?po=B3aczen_z_baza_danych_-_pos?==?ISO-8859-2?Q?tgresql_=3C-=3E_odbc?=
Połączenie bazy danych z wykonaniem polaczenia telefonicznego
[mssql] insert do tabeli na podstawie danych z innej tabeli
[oracle] Baza danych do kursy Introduction to Oracle9i:PL/SQL ? Skąd ją pobrać ?
zanotowane.pldoc.pisz.plpdf.pisz.plnawschodzie.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
