vfp9 + sp2 (.5815 и .7423) + ком-сервер + ... короче, перестали выполнятся sql запросы, содержащие внутри обращения к ХП в "чистом окружении" ком-сервера - целевая бд не открыта, set path к бд установлена правильно (запросы без ХП выполняются, бд автоматически открывается) ... на работе всЁ работает, но там, мне кажется, не sp2 стоит и фокс вообще не установлен "правильно" через инсталлятор, я щас в отпуске и посмотреть нет возможности и вообще мозги в отпускном ступоре )) + собственно в самой среде vfp тоже всЁ работает ожидаемо правильно ... что такое может быть?

вариант с предварительным открытием бд исключается!

Какая ошибка валится?

PaulWist
Какая ошибка валится?

процедура такая-то не найдена

Перекомпилить базу (чтобы ХП перекомпилились) для начала... Может даже восстановить из бэкапа (контейнер)

Igor Korolyov
Перекомпилить базу (чтобы ХП перекомпилились) для начала... Может даже восстановить из бэкапа (контейнер)

превед, игорь ... но ведь если я прямо открываю бд перед запросом, то запрос выполняется ... завтра попробую пошаманить с бд, спасибо

Если ты открыл БД и она текущая, то все её ХП подключаются и становятся видимыми. Если БД не открыта или не является текущей, то её ХП недоступны.
Из контекста выполняющегося запроса БД должна быть открыта, но, возможно, что-то переключает её и делает "не текущей". Если COM-сервер многопоточный, то там вообще хз как разруливается всё это - это вообще другой рантайм.

Igor Korolyov
Перекомпилить базу (чтобы ХП перекомпилились) для начала... Может даже восстановить из бэкапа (контейнер)

перекомпиляция не помогла, бд та же, чтои на работе по идее

Подсказка уже была, но, похоже, не заметили

Если работа происходит в Private DataSession и открытие базы данных происходит автоматически при первом обращении к DBF, то база данных, конечно, откроется. Но вот текущей она не станет Соответственно, не будут "видны" хранимые процедуры

Если же база данных была открыта еще в Default DataSession и была установлена как текущая, то, как правило, в Private DataSession она также остается текущей. Что и можно наблюдать при работе из среды разработки

Так что, вариантов два

1. Работать в Default DataSession
2. При работе в Private DataSession все-таки предварительно вручную открывать базу данных и явно делать ее текущей

Ну, или извлечь процедуры из контейнера базы данных в обычные PRG, которые и включить в Com-сервер. Или рядом с DBF положить. Но не уверен, что com-сервер сможет работать со свободно лежащими PRG

Владимир Максимов
Подсказка уже была, но, похоже, не заметили
Если работа происходит в Private DataSя ession и открытие базы данных происходит автоматически при первом обращении к DBF, то база данных, конечно, откроется. Но вот текущей она не станет Соответственно, не будут "видны" хранимые процедуры

Если же база данных была открыта еще в Default DataSession и была установлена как текущая, то, как правило, в Private DataSession она также остается текущей. Что и можно наблюдать при работе из среды разработки

Так что, вариантов два

1. Работать в Default DataSession
2. При работе в Private DataSession все-таки предварительно вручную открывать базу данных и явно делать ее текущей

Ну, или извлечь процедуры из контейнера базы данных в обычные PRG, которые и включить в Com-сервер. Или рядом с DBF положить. Но не уверен, что com-сервер сможет работать со свободно лежащими PRG

пасиб, володя ... да, базовым классом для комсервера является SESSION и когда я снаружи запрашиваю this.DataSession он возвращает 2, изменить еЁ не удаЁтся, попробовал сделать базовым классом CUSTOM, но ничего не изменилось, придЁтся, наверное, выносить функции из контейнера бд ... не знаю подхватит ли комсервер процедурные файлы рядом "на лету", но если ему снаружи настроить set procedure он отлично с ними работает

А почему не переключить на нужную БД

Чтобы переключиться её нужно явно открыть для начала

В ком-сервере есть свои нюансы, но по идее fxp он выполняет без вопросов, если они будут в set path или по set proc подключены (конечно же prg он сам не откомпилирует, и я не уверен что COMPILE в этом рантайме доступен - хотя хелп и не говорит явно что недоступен).

А почему бы их действительно просто не вкомпилировать внутрь dll? Неужто нужна такая предельная гибкость, чтобы снаружи разный код подсовывать?

NSF
да, базовым классом для комсервера является SESSION и когда я снаружи запрашиваю this.DataSession он возвращает 2, изменить еЁ не удаЁтся

Session это правильный выбор. Поменять DataSession можно лишь в дизайнтайме (т.е. создав свой класс-наследник Session и там прописав свойство) - во время исполнения это свойство readonly. Но я бы крайне не советовал это делать. Изолирование сессий это корректный вариант работы. Но да, вероятно он требует явного открытия БД и установки её как текущей (если предполагается работа с ХП).
Я всё же не вижу в чём состоит сложность прописать код для открытия и установки нужной БД как текущей - где-то в инициализирующем/сетап методе этого ком-сервера, к примеру (или, если он настолько умён что сам может найти БД и не нуждается в переданных из основного процесса параметрах/путях, то в том же Init).

Igor Korolyov

NSF
да, базовым классом для комсервера является SESSION и когда я снаружи запрашиваю this.DataSession он возвращает 2, изменить еЁ не удаЁтся

Session это правильный выбор. Поменять DataSession можно лишь в дизайнтайме (т.е. создав свой класс-наследник Session и там прописав свойство) - во время исполнения это свойство readonly. Но я бы крайне не советовал это делать. Изолирование сессий это корректный вариант работы. Но да, вероятно он требует явного открытия БД и установки её как текущей (если предполагается работа с ХП).
Я всё же не вижу в чём состоит сложность прописать код для открытия и установки нужной БД как текущей - где-то в инициализирующем/сетап методе этого ком-сервера, к примеру (или, если он настолько умён что сам может найти БД и не нуждается в переданных из основного процесса параметрах/путях, то в том же Init).

он настолько умЁн, что является лишь посредником для вызовов функций из внешних процедурных файлов, т.е. внести описанные изменения тобой вообще не проблема, если не считать, что функция, запускающая переданный sql-запрос и возвращающая xml, предполагается универсальной ...правильней видится просто из контейнера убрать хп ... и не терпится уже попасть на работу и посмотреть что там за зверь вообще стоит и почему всЁ работает ))

Igor Korolyov
Чтобы переключиться её нужно явно открыть для начала
В ком-сервере есть свои нюансы, но по идее fxp он выполняет без вопросов, если они будут в set path или по set proc подключены (конечно же prg он сам не откомпилирует, и я не уверен что COMPILE в этом рантайме доступен - хотя хелп и не говорит явно что недоступен).

А почему бы их действительно просто не вкомпилировать внутрь dll? Неужто нужна такая предельная гибкость, чтобы снаружи разный код подсовывать?

ещЁ как доступен, игорь ... и, по-моему, он может при отсутствии fxp и скомпилировать иначе он не мог бы работать с execscript ... имхо канешна

нет, неправ, если fxp нет, то set procedure выкидывает исключение ... но compile работает: когда я на интерфейсе сервера подключаю процедурный файл, то автоматически компилирую его с анализом и выдачей ошибок





Исправлено 1 раз(а). Последнее : NSF, 16.05.20 16:27

Даже обычный рантайм сам не выполняет compile и, соответственно, не запускает код из prg - надо явно его вызывать для создания fxp
А в общем случае создавать fxp из prg не так то и просто - нужно обеспечить правильный environment - те же пути задать, чтобы были найдены .h файлы...
execscript это упрощённый вариант, и тоже не без своих нюансов - хорошо когда ты в них "влазишь", а если нет, то увы... тот же define class для создания доступного извне скрипта описания класса уже не получится соорудить...
Благо в 99% случаев все эти сложности попросту не нужны Собственно и сам execscript это функционал для 1% случаев - не так уж и часто он нужен.

Igor Korolyov
Чтобы переключиться её нужно явно открыть для начала
В ком-сервере есть свои нюансы, но по идее fxp он выполняет без вопросов, если они будут в set path или по set proc подключены (конечно же prg он сам не откомпилирует, и я не уверен что COMPILE в этом рантайме доступен - хотя хелп и не говорит явно что недоступен).

А почему бы их действительно просто не вкомпилировать внутрь dll? Неужто нужна такая предельная гибкость, чтобы снаружи разный код подсовывать?

речь в данном случае идЁт именно про маленького посредника из потоков висящих на completetion port между сервером и функциями в процедурных файлах ... ну сам посуди: вот процедурный файл с функциями о которых "знает" и вызывает клиент для работы с бд фокса и вот такой же для работы с mssql ... конечно универсально

Igor Korolyov
Даже обычный рантайм сам не выполняет compile и, соответственно, не запускает код из prg - надо явно его вызывать для создания fxp А в общем случае создавать fxp из prg не так то и просто - нужно обеспечить правильный environment - те же пути задать, чтобы были найдены .h файлы...
execscript это упрощённый вариант, и тоже не без своих нюансов - хорошо когда ты в них "влазишь", а если нет, то увы... тот же define class для создания доступного извне скрипта описания класса уже не получится соорудить...
Благо в 99% случаев все эти сложности попросту не нужны Собственно и сам execscript это функционал для 1% случаев - не так уж и часто он нужен.

да-да, игорь, я проверил, был неправ по поводу компилиции на лету

Igor Korolyov
Даже обычный рантайм сам не выполняет compile и, соответственно, не запускает код из prg - надо явно его вызывать для создания fxp А в общем случае создавать fxp из prg не так то и просто - нужно обеспечить правильный environment - те же пути задать, чтобы были найдены .h файлы...
execscript это упрощённый вариант, и тоже не без своих нюансов - хорошо когда ты в них "влазишь", а если нет, то увы... тот же define class для создания доступного извне скрипта описания класса уже не получится соорудить...
Благо в 99% случаев все эти сложности попросту не нужны Собственно и сам execscript это функционал для 1% случаев - не так уж и часто он нужен.

execscript в комсерверах не редкость: всегда ищешь баланс между многократным дЁрганьем интерфейса комсервера и временем затрачиваемым на компиляцию кода собранного в execscript

В большинстве случаев execscript и прочая "динамика" (включая макро в запросах или ином коде) это прямой путь для инъекции зловредного кода