Текущий архив: 2002.07.15;
Скачать: CL | DM;
ВнизХранимая процедура в пакете Найти похожие ветки
← →
Nonam (2002-06-20 14:36) [0]Хранимые процедуры находятся в пакете (package body) и из компонета TStoredProc их не видно. Как обратится к процедуре, находящейся в пакете?
← →
Val (2002-06-20 14:39) [1]pkg_name.proc_name
← →
Johnny Smith (2002-06-20 15:20) [2]2Nonam (20.06.02 14:36)
Хранимые процедуры находятся в пакете (package body) Процедуры должны находиться не просто в теле пакета (package body), но и объявлены в заголовке пакета. Тогда они будут доступны извне.
← →
Nonam (2002-06-20 16:54) [3]2 Johnny Smith
Это естественно. Вы не создадите package body, если до того не объявите package. Проблема, кажется, в другом. Я не могу из Delphi доступиться ни к одному пакету. Ни к своим, ни из других схем, хотя SQL Explorer их показывает.
← →
dimis (2002-06-20 17:02) [4]>>Nonam
вы не правы
процедуру вполне можно объявить только в package body
но тогда она будет доступна только внутри пакета.
(interface... implemantation в Паскале)
попробуйте как и советует Val ручками прописать её имя
я использую ODAC и там все прекрасно видно
← →
Judith (2002-06-20 17:23) [5]Ручками, ручками, причем большими буквами. А если процедура с параметрами, то в BDE установить DLL32 SQLORA32.DLL
← →
Nonam (2002-06-20 17:24) [6]2dimis
Вы не создадите package body, если до того не объявите package. Уточняю - речь идет не о процедуре внутри package body, а именно о package body. Если быть совсем точным, то создать package body без package можно, но вылетит "Warning: Package Body created with compilation errors." и пользоваться этим пакетом вы не сможете.
← →
Nonam (2002-06-20 17:50) [7]2Judith
Вы оказались совершенно правы во всем - и про SQLORA32.DLL, и про большие буквы. Спасибо. Правда, не совсем понятно. В хелпе к BDE Admin фирма Borland рекомендует для Oracle8 использовать SQLORA8.DLL, а SQLORA32.DLL - для Oracle7. Выходит, старая библиотека корректнее, чем новая? И это в Delphi6!
← →
MishGan` (2002-06-20 17:59) [8]Честно говоря я никогда бы не стал использовать BDE для доступа к ORACLE. Проблем может быть много всяких и разных (тут их всех и не перечислишь).
ИМХО лучше для этих целей использовать специальные компоненты прямого доступа работающие через OCI (например DOA,ODAC и т.д.) Там и возможностей побольше, да и нет проблем использованием специфичных фишек ORACLE, которых нет в других СУБД (не будем забывать, что BDE это все же _универсальный_ механизм для доступа к БД), таких как PACKAGE, NESTED TABLES, DBMS_PIPE, DBMS_ALERT и т.д.
← →
Val (2002-06-20 18:50) [9]>MishGan` (20.06.02 17:59)
ну не будьте столь категоричны, а если проект существует совсем не один год и этих компонент просто не было? Полная переделка, это, знаете ли...
← →
MishGan (2002-06-20 19:23) [10]2 Val
Мы полтора года назад перешли с BDE на DOA. До этого софт писался на BDE года 4. Сам переход (написание кода, отладка) занял несколько дней (проект относительно небольшой - ~150000 строк кода), но перевести всех клиентов удалось где-то за полгода (даже чуть больше).
Но зато теперь все довольны хоть.
Единственный момент - у нас все это получилось относительно просто, потому что все обращения к СУБД идут через специально написанную библиотеку для работы с БД. А вот если на каждой форме были набросаны всякие там TTable и TQuery - то я представляю, сколько бы мы тогда возились (и сколько багов бы потом вылезло).
Страницы: 1 вся ветка
Текущий архив: 2002.07.15;
Скачать: CL | DM;
Память: 0.46 MB
Время: 0.011 c