Net i Ja » kod

„ORA-12838: cannot read/modify an object after modifying it in parallel”

Marek — Tue, 15 Feb 2011 09:13:11 +0000

Niby prosty insert na podstawie selekta:


INSERT /*+ APPEND */ SELECT * FROM test;

A w efekcie można uzyskać brzydki błąd. Jego rozwiązanie jest dość banalne.

Wystarczy zapytanie zakomitować:


COMMIT;

Kolejna porcja komend dla vim-a ;)

Marek — Fri, 26 Nov 2010 12:57:38 +0000

Duplikowanie linii w której znajduje się kursor:

(tryb komend) yyp

Usuwanie linii w której znajduje się kursor:

(tryb komend) yyd

Wyświetlenie pomocy kontekstowej

(tryb edycji) Ctrl+N

create table as select where rownum, czyli o tworzeniu kopi tabeli z ograniczeniami

Marek — Thu, 21 Oct 2010 06:32:30 +0000

Czasem w czasie procesu testowania stworzonych procedur lub większych zapytań sql pojawia się potrzeba częstego ich testowania. Jednak często oryginalne dane, które mamy przetwarzać są zbyt duże by testy przeprowadzać w trakcie powstawania kodu. Dobrym rozwiązaniem tego problemu jest stworzenie kopi tabel z małą próbką testową orginalnych danych.

Kod stworzenia kopi tabeli, gdzie n jest zadaną ilością wierszy kopiowanych:


create table tablica_kopia as
 select * from tablica_orginalna
 where rownum <=n;

Gdy konfiguracja apache nie pozwala na „php_flag magic_quotes_gpc Off”

Marek — Wed, 19 May 2010 16:30:46 +0000

Na niektórych hostingach bywa tak, że z pewnych względów poniższy kod nie zadziała, a wskutek tego np ckeditor też poprawnie nie będzie interpretowała tworzonych linków.


php_flag magic_quotes_gpc Off

Rozwiązanie problemu okazało się banalne:


SetEnv MAGIC_QUOTES 0

„ORA-06553: PLS-382: expression is of wrong type” i tablica dual

Marek — Wed, 05 May 2010 08:17:50 +0000

Kilka dni temu zacząłem się trochę więcej bawić z bazą danych Oracle i od razu napotkałem klika niespodzianek Oto jedna z nich. Pisałem funkcje składowaną, która po wykonaniu jakiś zapytań na bazie i sprawdzeniu kilku warunków miała zwrócić true lube false, a z racji że PL/SQL udostępnia cudowny typ BOOLEAN to zapragnąłem własnie z niego skorzystać.


create or replace function czy_spelnione_wymagania(
 pesel IN varchar2,
 temat IN varchar2)
 return boolean
 is

....

Funkcja się skompilowała poprawnie, więc cały szczęśliwy chciałem ją przetestować korzystając z zabawnej tablicy DUAL.


SELECT czy_spelnione_wymagania('8089123243','Oaza Nowego Zycia 1') FROM DUAL;

I tu mnie spotkało niemiłe zaskoczenie:


ORA-06552: PL/SQL: Statement ignored
ORA-06553: PLS-382: expression is of wrong type

Zasięgnąłem informacji o błędzie i byłem dość zaskoczony tym co było przyczyną. A mianowicie poczciwy SQL nie obsługuje udostępnianego przez PL/SQL typu BOOLEAN! Więc trzeba to obejść jakoś ładnie i poniżej przedstawiam moją propozycje rozwiązania tego problemu za pomocą bloku PL/SQL.


DECLARE
VAR_BOOL BOOLEAN;
BEGIN
VAR_BOOL :=czy_spelnione_wymagania();
IF( VAR_BOOL = TRUE ) THEN
DBMS_OUTPUT.PUT_LINE( ‘TRUE’ );
END IF;
END;

Tak więc nie jesteśmy zmuszeniu do modyfikacji formatu zwracanych danych przez naszą funkcje składowaną, ale oczywiście jak ktoś bardzo lubi to może sobie przyjąć, że będzie zwracał int, gdzie FALSE = 0 a TRUE = 1.

Dostęp do bazy danych w Bootstrap-erze… i można ;)

Marek — Wed, 20 Jan 2010 00:15:38 +0000

Pisząc dziś projekt z Bezpieczeństwa Aplikacji Internetowych zatrzymał mnie na chwilkę pewien problem…
Jak skorzystać z bazy danych już na poziomie bootstrapera?

W domyślnie wygenerowanym projekcie za pomocą narzędzia Zend_Tool, czyli wpisujemy w konsoli tak:

zf create project nazwa_projektu sciezka_projektu

Oprócz fajnej struktury katalogów otrzymujemy plik konfiguracyjny naszego projektu w prezencie. Znajduje się on w .\application\configs\application.ini i wygladajakoś tak:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

Mając taki ładny czysty projekt, każdy pewnie chce go wyposażyć w dostęp do bazy danych. I tu czeka nas miła, bo ustawienie adaptera do naszej bazy jest banalnie prosta i polega tylko na dodaniu małej wstawki w plik konfiguracyjny widoczny powyżej.

...
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.db.adapter = PDO_MYSQL
resources.db.params.host = adres_bazy
resources.db.params.username = nazwa_konta
resources.db.params.password = haslo_dostepu
resources.db.params.dbname = nazwa_tablicy_w_bazie
[staging : production]
...

Powyższa czynność gwarantuje nam, bezproblemowy dostęp do tak skonfigurowanej bazy przy pomocy wszystkich klas z rodziny Zend_Db, w całym projekcie za wyjątkiem bootstrapera (.\application\Bootstrap.php). I tu właśnie się okazało, że w niektórych przypadkach i tam ten dostęp by był przydatny. Aby go uzyskać wystarczy przed naszym kodem korzystającym z dostępu do bazy ustawić domyślny adapter bazy danych, a raczej powiedzieć Zendowi gdzie leży jego konfiguracja. Pomoże nam w tym poniższy kawałek kodu:

...
$config = new Zend_Config_Ini('../application/configs/application.ini', 'production');
$db = Zend_Db::factory($config->resources->db);
Zend_Db_Table::setDefaultAdapter($db);
...

I można już odpytywać bazę danych i tu