Запуск SQL запроса из Blob поля на сервере
Запуск SQL запроса из Blob поля на сервере
Нужно в хранимой процедуре запустить SQL запрос, хранящийся в Blob поле одной их таблиц. Подскажите как?
Блин, короче есть записи в базе, они отправляются с нашего серванта на верх через нет, перед отправкой их надо проверить на коекакие условия, при внесении их в нашу базу проверить нельзя. Условия проверки могут меняться, желательно чтобы ненадо было из-за этого лезть в базу (поэтому есть таблица с ошибками, именно в ней завёл блоб поле с проверкой на эту ошибку). Сервак - Фаербёрд 1.5.3.Лысый писал(а):Опиши задачу подробнее, зачем это надо? Ну и версию серванта скажи...
вообще бред, по многим параметрам.Ещё трабла - как в хранимой процедуре подтвердить транзакцию? Дело в том, что я меняю тело другой хранимой процедуры из этой но пока транзакция не подтверждена эта вторая процедура остаётся старой...
1. операторы ddl можно выполнять только в отдельной транзакции, с обязательным commit после оператора. смешивание ddl и dml в одной транзакции не рекомендуется.
2. "изменить" процедуру из другой процедуры невозможно, и изменение rdb$procedure_source ничего не даст. нужно выполнять только оператор create/alter/recreate, чего в процедуре сделать нельзя.
3. существует кэш метаданных, который не меняется при alter procedure, если процедура используется. Читай доку (datadef.pdf, altering procedures in use.
А можно воздержаться от подобных коментов? Проблема то нестандартная...hvlad писал(а):Никак
Перед тем, как начать писать процедуры, неплохобы сначала изучить инструмент и как с ним обращаться
2kdv Я всё прекрасно понимаю, но тут выше изложено, что мне надо сделать, если транзакцию открыть и подтвердить внутри процедуры нельзя, то может у Вас есть идеи как мне решить мою проблему?
P.S. 2 - А вот и можно -
Код: Выделить всё
execute statement
'ALTER PROCEDURE TESTERR(
ID_CAR INTEGER,
ID_ORDER INTEGER)
RETURNS (
ERROR INTEGER)
AS
begin
/* Procedure Text */
ERROR=1;
Suspend;
end'
воздержаться - нельзя. у сервера есть архитектура, и все действия с ним допустимы в контексте архитектуры. В IB/FB так, в MS SQL эдак, в Оракле еще как то.А можно воздержаться от подобных коментов? Проблема то нестандартная...
в сад. нет никакой проблемы. ddl операторы ДОЛЖНЫ выполняться с клиента в ОТДЕЛЬНОЙ транзакции и завершаться COMMIT. Кроме того, все транзакции стартуют и завершаются только по инициативе клиента. Не нравится - переходи на другой сервер, который работает по другому. Или НЕ пытайся сделать так, как конкретный сервер не может и не должен. Грубо? Может быть. Зато правда.2kdv Я всё прекрасно понимаю, но тут выше изложено, что мне надо сделать, если транзакцию открыть и подтвердить внутри процедуры нельзя, то может у Вас есть идеи как мне решить мою проблему?
не можно. просто не запретили выполнять ddl в execute statement. я так понимаю, не дошли руки до того, чтобы это запретить. Поэтому "можно", только с непредсказуемыми последствиями.P.S. 2 - А вот и можно -
execute statement
Баааалин! Написал же "тут выше имеется проблема", можно сначала прочитать то, что тут выше, а потом людей в сад посылать, а?kdv писал(а):в сад. нет никакой проблемы. ddl операторы ДОЛЖНЫ выполняться с клиента в ОТДЕЛЬНОЙ транзакции и завершаться COMMIT. Кроме того, все транзакции стартуют и завершаются только по инициативе клиента. Не нравится - переходи на другой сервер, который работает по другому. Или НЕ пытайся сделать так, как конкретный сервер не может и не должен. Грубо? Может быть. Зато правда.
Нужно в хранимой процедуре запустить SQL запрос, хранящийся в Blob поле одной их таблиц. Подскажите как?
Я вот про эту проблему. Нельзя транзакции - ПРЕКРАСНО, тогда как это сделать? Главная фигня в том, что в такой запрос нуно передать параметры...Блин, короче есть записи в базе, они отправляются с нашего серванта на верх через нет, перед отправкой их надо проверить на коекакие условия, при внесении их в нашу базу проверить нельзя. Условия проверки могут меняться, желательно чтобы ненадо было из-за этого лезть в базу (поэтому есть таблица с ошибками, именно в ней завёл блоб поле с проверкой на эту ошибку). Сервак - Фаербёрд 1.5.3.
P.S. А на счёт execute statement - даж в руководстве написано
- почитай повнимательнее, такчто не руки недошли, а фишка это. (Firebird 1.5 realease notes v.1.08 Page 20)Executes <string> as SQL operation thet does not return any data rows, vis. insert, update, delete, execute procedure or ANY DDL STATEMENT exept create/drop database
Словами вашего же гуру - "Перед тем как админить форум неплохобы сначала изучить инструмент и т.д."...
Без обид.какая проблема, где? сначала придумываем какую-то муть, а потом пытаемся ее осуществить получая "проблему"?Баааалин! Написал же "тут выше имеется проблема", можно сначала прочитать то, что тут выше, а потом людей в сад посылать, а?
ну допустим execute statement. И что? Если не смущает, что в общем плане это решение кривое, и разработчики FB уже давно стонут из-за того, что дали "в кривые руки" execute statement, то пожалуйста, используй....Нужно в хранимой процедуре запустить SQL запрос, хранящийся в Blob поле одной их таблиц. Подскажите как?
ну ты ж читал relnotes. что тебе еще надобно?Главная фигня в том, что в такой запрос нуно передать параметры...
кто бы кому указывал, где читать внимательнее, и что фича а что недоделка, и кто тут вообще гуру из присутствующих.- почитай повнимательнее, такчто не руки недошли, а фишка это.
Это проверки данных на локальном сервере перед отправкой на глобальный - муть? Мило... Также можно сказать, что рекурсия - муть, ветвления - муть и вообще нормальные перци пишут так:
Я сам бы с большим удовольствием проверил в делфи, но заказчику надо чтоб на сервере...
Код: Выделить всё
mov ax,a
mov bx,b
add ax,bx
jnz AAA
...
AAA:я вашей постановки задачи не читал, и чего там хочет заказчик, я не знаю. в общем случае детали реализации не всегда его, заказчика, дело.
к тому же я не вижу никакой связи между запросом в blob, execute statement, и "проверкой" данных локально перед отправкой на сервер.
более того, я надеюсь, что протокол связи приложения с сервером позволяет убедиться, что правила проверки и там и здесь одинаковы. Если дальше развивать эту мысль, то я не уверен в адекватности используемого решения. То есть, в "проверке" данных "локально" перед отправкой "на сервер".
В целом, объединяя все изложенные в этом топике намеки на конкретную реализацию, я бы мог дальше спросить "а почему не используется 2PC" и задать другие вопросы, но это, извините, будет консультация по проектированию.
к тому же я не вижу никакой связи между запросом в blob, execute statement, и "проверкой" данных локально перед отправкой на сервер.
более того, я надеюсь, что протокол связи приложения с сервером позволяет убедиться, что правила проверки и там и здесь одинаковы. Если дальше развивать эту мысль, то я не уверен в адекватности используемого решения. То есть, в "проверке" данных "локально" перед отправкой "на сервер".
В целом, объединяя все изложенные в этом топике намеки на конкретную реализацию, я бы мог дальше спросить "а почему не используется 2PC" и задать другие вопросы, но это, извините, будет консультация по проектированию.
не надо развивать то, чего мной не было сказано. Есть серверные проверки. Есть клиентские проверки. Синхронизация клиентских проверок с серверными - еще один вариант. Который сложнее. Как вы там его делаете и зачем - я не знаю. И опять же не вижу связи между используемыми выкрутасами и вскользь описанной постановкой задачиЭто проверки данных на локальном сервере перед отправкой на глобальный - муть? Мило... Также можно сказать, что рекурсия - муть, ветвления - муть и вообще нормальные перци пишут так:
Данные на сервер идут в XML, на серваке оракул. Наше приложение работать может и на 2-х и на 3-х компах и вообще в WLAN на пол города с центральным офисом и филиалами. На счёт локальной проверки - передо мной лежит толмуд, на нем написано "Директор по организации поставок автомобилей, запчастей и техническому обслуживанию ____________ такойто", а дальше идёт таблица с описанием 50 проверок и 2-мя галочками 1 - проводится ли проверка на клиенте, 2 - проводится ли на сервере. ЗАЧЕМ это делается - вопрос к ВЦшникам ВАЗа, также как и почему они спроектировали такую ущербную БД работ по ремонту, я тут ни при чём, я таких бы вообще вешал. Короче в результате 20 минутного диспота с начальством я добился права реализовать ЭТО не на сервере БД, а там, где формируется XML. Всем спасибо за помощь.
Re: Запуск SQL запроса из Blob поля на сервере
Это называется или STORED PROCEDURE, или TRIGGER, или VIEW.Mor писал(а):SQL запрос, хранящийся в Blob поле одной их таблиц
Непонято: блоб меняется без того, чтобы лезть в базу ?Mor писал(а):Условия проверки могут меняться, желательно чтобы ненадо было из-за этого лезть в базу
Так что - моя рекомендация остаётся в силе
Re: Запуск SQL запроса из Blob поля на сервере
ЭТО называется запрос, мне не критично в какой он там форме, просто была идея сделать всё через процедуры. На данный момент там например:hvlad писал(а):Это называется или STORED PROCEDURE, или TRIGGER, или VIEW.
Непонято: блоб меняется без того, чтобы лезть в базу ?
Так что - моя рекомендация остаётся в силе
Код: Выделить всё
if (not exists(select * from ent e where e.vin =
(select c.vin3 from vcars c where c.id_car = :ID_CAR)
)) then begin
CODE=5;
suspend;
endБлоб меняется без изменения метаданных. Такчто твоя рекомендация остаётся бредом...