Pakiety są logicznym zbiorem obiektów takich jak podprogramy, typy, wyjątki, kursory. Składają się z części specyfikacji oraz implementacji. W części specyfikacji deklarujemy jedynie co ma zawierać pakiet, a w części implementacji „ciała” deklarowanych obiektów. Jeśli więc w części specyfikacji deklarujemy że pakiet zawierać ma procedurę „procedura1” z dwoma parametrami typu number, to w części implementacji musimy określić dokładnie jak ta procedura działa, a więc całość jej kodu.
Może istnieć deklaracja obiektu np. procedury w części specyfikacji bez rozwinięcia w części implementacji, ale nie może być odwrotnie. Obiekty w pakiecie mogą zasadniczo występować w dowolnej kolejności, poza sytuacją gdy procedura A odnosi się do procedury B – w takim wypadku procedura A musi być zadeklarowana wcześniej.
Przystępując do tworzenia pakietu musimy najpierw zdeklarować elementy z których pakiet ma się składać. Robimy to w części specyfikacji:
Na razie definiujemy jedynie jakie elementy mają się znaleźć w pakiecie, oraz jakie parametry mają przyjmować i zwracać procedury i funkcje.
Przechodzimy teraz do opisania sposobu działania funkcji i procedur tj. części „Body” pakietu.
„Zapowiedź” procedur i funkcji która pojawiła się w części specyfikacji pakietu, jest teraz rozwijana o implementację. Każda procedura i funkcja która pojawiła się w poprzednim przykładzie jest teraz napisana w całości. Wszystkie nazwy i typy parametrów są identyczne.
Mając już działający skompilowany pakiet mogę się odwołać do funkcji i procedur w nim zawartych:
Jeśli odwołuję się do funkcji/procedury zawartej w pakiecie z konsoli, podprogramu nie ujętego w pakiecie lub zawierającego się w innym pakiecie niż podprogram do którego się odwołuje, muszę podać nazwę pakietu przed nazwą wywoływanej funkcji. Jeśli odnoszę się do tego podprogramu z innego podprogramu zawartego w tym samym pakiecie, nazwy wywoływanej funkcji/procedury nie muszę poprzedzać nazwą pakietu.
Ten temat omawiam na poniższych szkoleniach:
• Programowanie w PL/SQL
• Podstawy SQL i PL/SQL
Możesz w nich uczestniczyć, a jako czytelnik tego bloga otrzymasz 10% zniżki - poinformuj o tym fakcie konsultanta.
"gdy procedura A odnosi się do procedury B – w takim wypadku procedura A musi być zadeklarowana wcześniej."
OdpowiedzUsuńMoim zdaniem to procedura B musi być zadeklarowana wcześniej. Jeśli A ma się odnieść do B, to aby było to możliwe B musi istnieć (przed A). Domyślam się, że pewnie przeoczenie z Twojej strony. Pozdrowienia.
Warto byłoby napisać o zasięgu tego co jest pisane w SPECu. "Może istnieć deklaracja obiektu np. procedury w części specyfikacji bez rozwinięcia w części implementacji, ale nie może być odwrotnie" - to zdanie nie jest prawdą. Wszystko co jest pisane w specu jest publiczne w obrębie schematu. Oczywiście można pisać funkcje, procedury w BODY bez podawania deklaracji w specyfikacji. Wtedy są widziane tylko wewnątrz pakietu.
OdpowiedzUsuńZnalazłem mały błąd - zakończenie pakietu powinno się definiować poprzez END [nazwa_pakietu];
OdpowiedzUsuńPozdrawiam
to nie błąd tylko dobra praktyka..
UsuńTen komentarz został usunięty przez autora.
OdpowiedzUsuńNajlepszą metodą na wywołanie pakietu i ich metod to wywołanie przez kod anonimowy .
OdpowiedzUsuń