А я согласен с Dim2000. ESQL есть вполне штатное средство и запрещать использовать его так же глупо как запрещать использовать DW.

В очень многих случаях намного удобнее и быстрее послать изменения в базу через ESQL'ные INSERT/UPDATE/DELETE чем заводить ради одной переменной dataobject и класть его в pbl. Тоже самое насчет создания DataStore на основе SQLCA.SyntaxFromSQL, плюс еще десяток строк - смена параметров свежесозданого DataStore объекта. И все это ради того чтобы повторить функциональность одной SQL команды???

ЗоринАндрейЯ не сталкивался за последние 10 лет с глюками при сохранении DW которые нельзя было бы обойти, в худшем случае - с помощью пары тройки десятков строк кода.
Все верно. Обойти глюки можно. И способо обхода тоже множество.
Вот только потом, когда надо поменять функциональность или исправить обнаруженую ошибку приходится долго и муторно бегать по десятку окошек.
Проверь event'ы и функции навешаные на конкретный dw contorl, потом проверь pfc_* event'ы и функции навешаные на окно. Потом пойди в родителя этого окна и проверь все эти события и функции там. Потом вернись в потомка проверь их все заново.... Все это чрезвычайно муторно и неприятно.
Намного проще когда вся процедура сохранения данных находится в одном месте. Пусть даже и написана она на чистом ESQL.

PL99 White OwlВ очень многих случаях намного удобнее и быстрее послать изменения в базу через ESQL'ные INSERT/UPDATE/DELETE чем заводить ради одной переменной dataobject и класть его в pbl.Оно конечно, заплатку налепить быстрее... Как обеспечить корректное разграничение доступа при таком использовании ESQL?
Э? Что там разграничивать? Разграничение доступа к отдельным таблицам по принципу имени или группы юзера деалается на уровне базы данных. Никак не приложения.
То есть вполне хватит проверить SQLCA.SQLCode после выполнения ESQL команды и если в данном конретном месте возможно получить отлуп по недостатку прав выдать соотвествующее предупреждение пользователю или проигнорировать ошибку... Ну как захочется :)
А во вторых, та же самая проблема есть и при использовании DW. Точно так же можно получить dw_1.Update() = -1 при нехватке прав.
В любом случае, проблема разграничения доступа никак не связана с решением использовать ESQL в данном конкретном месте или заводить специальный datastore.

PL99Все это можно только через специализированные сервисы, инкапсулирующие ESQL вызовы и обеспечивающие всю обвязку - проверку ошибок, разграничение доступа и т.п. В случае использования DW/DS все это должно быть реализовано в соответствующих предках.
Все равно этого предка еще надо делать. А во вторых, опять же на все случаи жизни предков не напасешься. В любом варианте тебе прийдется модифицировать предка под сиюминутные нужды. Имя таблицы там поменять или фильтр по другому построить. Все равно при использовании даже заранее сочиненного u_super_dw_for_update прийдется писать несколько настроечных строк. Да еще и прийдется помнить какие именно настройки это u_super_dw_for_update требует :)
А так, одна строка:
update sometable a set f1=(select f2 from othertable b where a.fk=b.pk and a.pk=:iRowId);
И вся проблема решена :)

PL99Вот именно. Если архитектура приложения для изменения функциональности требует подобных действий, может стоит задуматься - а не поменять ли что-нибудь в консерватории?
Ой, да я бы с удовольствием. Но эта архитектура естественное следствие идиотской PowerBuilder'овской системы наследования объектов и его кривой реализации редактора евентов/функций.
Ну почему для редактирования одного евента надо обязательно закрыть другой? Почему нельзя одновременно открыть на экране два евента одного объекта? Почему нельзя открыть и окно-родителя и окно-потомка и вместе их рассматривать?

ASCRUSГм, логику в БД выносите, и не будет религиозных войн
Религиозные войны идут и по вопросу выносить логику в БД или не выносить :)

А даже если логика и вынесена с клиента на сервер все равно этой логикой еще и управлять как-то надо. Данные ей кидать, указывать по какому из принципов обрабатывать вот эти конкретные данные. Мы ж тут и флудим про то как именно указывать, как именно кидать данные :)

Филипп White OwlНо эта архитектура естественное следствие идиотской PowerBuilder'овской системы наследования объектов и его кривой реализации редактора евентов/функций.
Ну почему для редактирования одного евента надо обязательно закрыть другой? Почему нельзя одновременно открыть на экране два евента одного объекта? Почему нельзя открыть и окно-родителя и окно-потомка и вместе их рассматривать?

А это что за бред?
К сожалению, вам Филипп, этого не понять.
Вот если бы у вас был опыт писания на Java/C++/Delphi/whatever а не один только PowerBuilder, то вы бы сами все это увидели бы.

PL99 White OwlТо есть вполне хватит проверить SQLCA.SQLCode после выполнения ESQL команды и если в данном конретном месте возможно получить отлуп по недостатку прав выдать соотвествующее предупреждение пользователю или проигнорировать ошибку... Ну как захочется :) Во-во. Именно о таком кривом коде я и говорил.
А что в этом кривого? Если ты используешь dw_1.Update ты получаешь все тоже самое. Точно так же прийдется заниматься отловом ошибки и разбираться почему именно. Только не при вызове dw_1.Update() а в dw_1.dberror.
Конечно более красиво и чисто было бы просто не допускать вызова ESQL команды update или dw_1.Update() если пользователь заведомо получит отлуп по недостатку прав. Но и в том и в другом варианте принцип работы совершенно одинаков. Еще раз повторю, с точки зрения разграничения прав нету разницы чем пользоваться - dw или esql.

PL99 White OwlВсе равно этого предка еще надо делать. А во вторых, опять же на все случаи жизни предков не напасешься. Почему-то у меня таких проблем нет, на все случаи жизни давным давно заведены соответствующие сервисы.
Иех, хорошо наверное жить в конторе, в которой специалисты на протяжении десятилетий вылизывает одну единственную библиотеку.

PL99В том числе и для таких постоянно применяемых, а не сиюминутных вещей , как White OwlИмя таблицы там поменять или фильтр по другому построить.. Если же задача новая, то написать код, пригодный для повторного использования, и оформить его в виде сервиса мне удобнее/проще/дешевле, чем лепить какие-то невнятные тексты...
Ок. Есть база, в базе две сотни таблиц. Нужно в этих таблицах обновлять значения отдельных полей. Покажи мне подготовленный заранее сервис который справится с такой задачей в одну строку при сиюминутном использовании.
Покажи мне сервис использование которого позволит мне убрать из кода строки типа
select max(f1) into :tmp from dba.t1;
и
insert into dba.t2 (f2) values (:tmp);
Чтоб он работал для любой из сотни имеющихся таблиц, с любым полем в этих таблицах. Я хочу посмотреть на такой сервис.


PL99 White OwlВсе равно при использовании даже заранее сочиненного u_super_dw_for_update прийдется писать несколько настроечных строк. Да еще и прийдется помнить какие именно настройки это u_super_dw_for_update требует :)Настроечная информация хранится в соответствующих таблицах/файлах/разделах реестра и называется метаинформацией. А помнить надо только наименование документа, где эти фичи (и все прочие) документированы.
Все равно, на все случаи жизни заранее сочиненых настроек не напасешься. Затем возможность настроек и делается чтобы их можно было при нужде менять, верно? Но менять то их все равно прийдется. Так зачем строить свою систему, для замены SQL если этот самый SQL уже доступен? Вот если делать систему которой клиент сможет рулить, тогда да - прийдется сочинять настроечные таблицы. Но мы же не о клиентах сейчас говорим, а о себе любимых. Зачем самому себе делать лишний уровень системной инкапсуляции?


PL99 White OwlА так, одна строка:
update sometable a set f1=(select f2 from othertable b where a.fk=b.pk and a.pk=:iRowId);
И вся проблема решена :)Я бы не стал раздувать флейм, если бы волею судьбы мне не приходилось сейчас рыть код, в котором в течении четырех лет все проблемы решали подобным образом.
Ха! А я уже четвертый год довожу до ума проект в котором все запросы к базе решали созданием новых dw. У меня на руках три десятка pbl с сотней dw в каждой. Как ты думаешь сколько там совершенно одинаковых dw различающихся только именем? А? :) А сколько времени надо убить чтобы найти в которой именно из pbl лежит нужный dw? А как весело когда в двух разных pbl лежат два разных dw с одинаковыми именами...
Я бы тоже не стал раздувать флейм, если бы мои коллеги и предшественники почаще пользовались бы ESQL или SQLCA.SyntaxFromSQL. Весь код по объему сократился бы вдвое как минимум.

PL99Вы пятую версию PB используете или четвертую? Впрочем, неважно... Какая связь между архитектурой приложения и реализацией среды разработки? А вот система наследования вполне соответствует принципам ООП, поясните, что там такого идиотского?
Девятую я использую. А среда разработки здесь очень сильно вмешивается. Когда ты делаешь даже простую двузвенку родитель-потомок тебе очень часто приходится переключаться между ними пока разбираешься какой код остается в родителе, а какой выносится в потомка. PB требует чтобы потомок и родитель были уже скомпилированы и лежали в pbl готовом для линковке виде так? Так. А это значит, что если мы добавили в одного потомка некую функциональность, потом собираемся перенести эту функциональность в родителя нам прийдется несколько раз делать код-заглушку или коментарить весь кусок недописаного кода целиком чтобы пойти и проверить как это делалось раньше...
В итоге, очень велика вероятность просто забыть убрать заглушку или снять коментарий. Сделаные, только ради того, чтобы PB позволил нам посмотреть на другой участок кода.
Тоже самое относится и к кодированию евентов/функций. Если в двух сходных функциях надо сделать copy/paste или просто посмотреть имя/параметры вызываемой функции, или уточнить смысл какого-то параметра.... Все равно прийдется делать заглушки/коментарии требующиеся исключительно для удовлетворения PB-шной среды.
Принципы ООП не нарушаются, но увеличивается шанс допустить ошибку.

PL99Впрочем, что-то мне подсказывает, что возможность открыть код предка и потомка одновременно в двух окнах не избавило бы вас от желания легко и просто написать строчку ESQL... А вот использовать copy&paste? наоборот, поощрило бы...
Как говаривал один мой знакомый "Зачем нужно модульное программирование, если есть блочное копирование?" :)
Copy&paste не так уж и плохо. Плохо если оно используется без ума :)
А ESQL как я уже говорил - очень полезная и правильная возможность.

zuzuдля этого я открываю две IDE PowerBuilderа на тотже прожект, покачто глюков от этого не заметил.
Сумасшедший.

ЗоринАндрей А сколько времени надо убить чтобы найти в которой именно из pbl лежит нужный dw?Бред.

Слову "бред" ты научился у Филиппа или это спецефическая фенечка этого форума? :)
Ну тут я конечно погорячился слегка (смущенно краснеет). Я предпочитаю искать при помощи FARа и pbldump. Тоже вполне быстро и удобно получается.

ЗоринАндрейБред.
Открываем предка и любых его потомков через Edit Source и резвимся как хотим. ;-)
Можно конечно, только неудобно :)