Как я победил Oracle. 2 из 2.
Но в целом-то всё закончилось хорошо.
Во-первых и в главных - ведь еще в первой части я добился понимания и работоспособности связки sqlplus-php, то есть таблица, созданная в консоли sqlplus могла быть прочитана из консольной версии php уже тогда, а это, в целом, значило, что так-то всё работает. Оставалось исправить несколько косяков:
Во-первых - переменные в Апаче. То, что он не видит ORACLE_HOME и LD_LIBRARY_PATH лечится (пока еще, хоть и на systemd) прописыванием переменных ORACLE_HOSTNAME, ORACLE_UNQNAME, ORACLE_BASE, ORACLE_HOME, ORACLE_SID и, конечно, LD_LIBRARY_PATH в файл /etc/sysconfig/httpd, по крайней мере на CentOS 7 это сработало. Безо всяких там export-ов, чистые утверждения <ПЕРЕМЕННАЯ>=<значение>. Наверное в следующих версиях СэнтОСа это отвалится, потому что systemd всё еще поддерживает /etc/sysconfig чисто из жалости. Это временно.
Во-вторых кроме OCI8 нужна была еще библиотека PDO_OCI, которая ну никак не собирается через pecl install или через phpize, configure и make после pecl download, выдавая либо, что не поддерживает вашу версию базы, но это легко патчится инфой из интернета, либо, что function чё-то там идите домой в общем. Собрать это всё, конечно, можно, но почти гарантированно работать это не будет, выдавая inidentified reference уже в самом выходном pdo_oci.so файле. А ответ прост - не парьте мозг. Интернет сплошь и рядом советует ставить oci8 и pdo_oci через pecl, а ни в центосе ни в самом пыхе это давно уже не поддерживается всерьёз. Так, если повезет. А не повезет. Просто скачайте исходники пыха, зайдите в директорию ext в них, дальше, например, в pdo_oci, и там сделайте phpize, ./configure и make install, ничего никак не патча, и никакие пути конфигьюру не передавая - всё это баловство, а всё должно просто работать.
В-третьих всё таки надо было дать возможность программистам программировать. А на АПЕКСе свет клином вовсе-то и не сошелся. Бесплатное приложение SQL Developer - это локальная программа (то есть ставится не на сервак, а на комп программиста), которая даёт в плане работы с таблицами в базе ровно то же самое, что и АПЕКС. Так что качаем. ставим хоть под винду, хоть под rpm-based-Linux, прописываем логины-пароли-хосты, и работаем с базой не трудней, чем работали бы с MySQL в phpMyAdmin.
После исправления трёх этих основных косяков, сайтик, залитый на тот сервак, что я делал снуля, просто взял и взлетел. Ура.
Во-первых и в главных - ведь еще в первой части я добился понимания и работоспособности связки sqlplus-php, то есть таблица, созданная в консоли sqlplus могла быть прочитана из консольной версии php уже тогда, а это, в целом, значило, что так-то всё работает. Оставалось исправить несколько косяков:
Во-первых - переменные в Апаче. То, что он не видит ORACLE_HOME и LD_LIBRARY_PATH лечится (пока еще, хоть и на systemd) прописыванием переменных ORACLE_HOSTNAME, ORACLE_UNQNAME, ORACLE_BASE, ORACLE_HOME, ORACLE_SID и, конечно, LD_LIBRARY_PATH в файл /etc/sysconfig/httpd, по крайней мере на CentOS 7 это сработало. Безо всяких там export-ов, чистые утверждения <ПЕРЕМЕННАЯ>=<значение>. Наверное в следующих версиях СэнтОСа это отвалится, потому что systemd всё еще поддерживает /etc/sysconfig чисто из жалости. Это временно.
Во-вторых кроме OCI8 нужна была еще библиотека PDO_OCI, которая ну никак не собирается через pecl install или через phpize, configure и make после pecl download, выдавая либо, что не поддерживает вашу версию базы, но это легко патчится инфой из интернета, либо, что function чё-то там идите домой в общем. Собрать это всё, конечно, можно, но почти гарантированно работать это не будет, выдавая inidentified reference уже в самом выходном pdo_oci.so файле. А ответ прост - не парьте мозг. Интернет сплошь и рядом советует ставить oci8 и pdo_oci через pecl, а ни в центосе ни в самом пыхе это давно уже не поддерживается всерьёз. Так, если повезет. А не повезет. Просто скачайте исходники пыха, зайдите в директорию ext в них, дальше, например, в pdo_oci, и там сделайте phpize, ./configure и make install, ничего никак не патча, и никакие пути конфигьюру не передавая - всё это баловство, а всё должно просто работать.
В-третьих всё таки надо было дать возможность программистам программировать. А на АПЕКСе свет клином вовсе-то и не сошелся. Бесплатное приложение SQL Developer - это локальная программа (то есть ставится не на сервак, а на комп программиста), которая даёт в плане работы с таблицами в базе ровно то же самое, что и АПЕКС. Так что качаем. ставим хоть под винду, хоть под rpm-based-Linux, прописываем логины-пароли-хосты, и работаем с базой не трудней, чем работали бы с MySQL в phpMyAdmin.
После исправления трёх этих основных косяков, сайтик, залитый на тот сервак, что я делал снуля, просто взял и взлетел. Ура.