Ответ на »сообщение 339« (Cepгей Poщин)
___________________________
>>> Допускаю, что конкретно Вы можете предложить систему ввода и проверки полей лучше, чем сделали это авторы Delphi
А это тут причем?! Авторы Delphi не сделали механизма, который бы позволял по введенным в Edit'ы значениям формировать и отправлять на сервер запрос UPDATE. Вернее, сделали, но только один единственный -- грид. Если мне нужно работать с одной единственной записью и разнести поля этой записи по форме, то этого нет.

Ответ на »сообщение 338« (Fktrc)
___________________________
член Инициативного комитета Фонда Я ж ведь не с проповедью выступаю давайте без излишней сакральности :о), и потом, Дэльфу тоже не лохи придумывали, ПМСМ.
Так и думал, что за стилем изложения не разглядят человека Может Вы возмётесь за перевод. Я так и не понял, как db-подобные компоненты нам помешают в многопользовательской работе и как их отсутствие — поможет. В худшем случае решать проблемы взаимнх блокировок, или изменений придётся самостоятельно что с ними, что без них.

Ответ на »сообщение 337« (Сергей Перовский)
___________________________
Допускаю, что конкретно Вы можете предложить систему ввода и проверки полей лучше, чем сделали это авторы Delphi, вопрос в другом смогу ли конкретно я в сжатые сроки изучить эту систему и внести в неё изменения не поломав? Смогут ли тоже самое сделать еще 10 свежевыученных студентов?
То что происходит в подавляющем большинстве случаев так это "кладбище разбитых кораблей", если под кораблями понимать гениальные задумки авторов.

»сообщение 336«
Нет, ежу ясно, что задавать свойства нужно в одном месте, а не по всей программе. Поля ввода могут быть раскиданы по разным модулям, хотя бы на том основании, что тах захотел пользователь. А вот поля данных пользователю невидны и их мы вольны размещать там, где нам удобно. Все проверки правильности/доступности ввода над ними и должны производится. А уж где и сколько Edit`oв осуществляют ввод в каждое поле знать вовсе необязательно.
ClientDataSet (чтобы DBAware-компоненты нормально работали) -- это все же перебор. Если он один раз используется, почему не везде.
Допускаю, что для каждого конкретного случая можно найти оптимальное решение и изобрести свой велосипед, но во-первых это долго придумывать, во-вторых еще дольше исправлять, и в-третьих еще дольше въезжать в задумку после десяти правок разных программистов.

Ответ на »сообщение 335« (Cepгей Poщин)
___________________________


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

Так и думал, что за стилем изложения не разглядят человека :)
Автор, выступающий под ником Amris Mirddin - это Александр Владимирович Невский, член Инициативного комитета Фонда FirebirdSQL, Firebird Foundation voting member, переводчик материалов www.firebirdsql.org, соавтор статьи http://www.ibase.ru/devinfo/pslock.htm и наверняка многих других статей. Принимает активное участие в развитии FireBird. Также принимал участие в создании книги "Мир InterBase". Программирующий начальник отдела автоматизации, причем на его софт еще никто не жаловался :) Возраст его уже близок к пенсионному (а не то и уже), но до сих пор сохранил молодость духа и недюжинное чувство юмора, что Вы и видели. Изложено весьма доходчиво и незабываемо. :)

Ответ на »сообщение 333« (Cepгей Poщин)
___________________________
но умоляю используйте dbavare компоненты
Но умоляю, не используйте dbavare компоненты :)
Любая СУБД представляет собой конечный автомат, который меняет свое состояние при попытке ввести ошибочное значение. Причем разные СУБД будут вести себя по разному и смена может привести к необходимости переписывания значительной части кода.
Как сторонник ООП, я всегда начинаю с проектирования классов. У большинства классов есть свои диалоги для редактирования свойств с проверками допустимости значений и т.д. Если объекты данного класса нужно хранить в БД, то прописываются методы ToBD и FromBD. В режим редактирования СУБД переводится в ToBD только на момент записи уже проверенного на корректность значения. Взаимные блокировки при многопользовательской БД минимальны.
Таким образом, из всех dbavare компонентов используется только dbGrid и только в режиме чтения для выбора нужной строки.
Все проверки корректности локализованы в описании объекта, искать их по всему коду не требуется.

Хех! Опять старый спор про использование DBAware-компонент ;-)

Нет, ежу ясно, что задавать свойства нужно в одном месте, а не по всей программе. Но вот то, что для любой модификации записей нужно обязательно использовать ClientDataSet (чтобы DBAware-компоненты нормально работали) -- это все же перебор.

Ответ на »сообщение 334« (Fktrc)
___________________________
http://www.sql.ru/forum/actualthread.aspx?tid=212425&pg=3#1834381 Без переводчика трудно разобраться, хотя стиль изложения хорошо иллюстрирует то, что они напрограммируют.
По поводу возможных конфликтов (мы редактируем данные, а кто-то их уже изменил), то всё уже изобретено: у ClientDataSet есть событие OnReconcileError в котором можно спросить пользователя что делать в каждом конкретном случае используя стандартный же диалог TReconcileErrorForm.
Если требуется что то особенное создать с блокировками, то всё равно не понял чем этому помешали db-подобные компоненты, но наверно знания языка не хватило, чтобы понять :)

Ответ на »сообщение 333« (Cepгей Poщин)
___________________________

Ответ на »сообщение 328« (Torbins)
___________________________
Ну это конечно первоапрельская шутка была, но если серьёзно, то меня всегда удивляло, почему каждый "кулхацкер" считает своим долгом вместо dbAvare-компонентов (dbEdit, dbCheckBox и т.п.) "забубенить" свой фирменный стиль ввода данных.
http://www.sql.ru/forum/actualthread.aspx?tid=212425&pg=3#1834381

Ответ на »сообщение 328« (Torbins)
___________________________
Ну это конечно первоапрельская шутка была, но если серьёзно, то меня всегда удивляло, почему каждый "кулхацкер" считает своим долгом вместо dbAvare-компонентов (dbEdit, dbCheckBox и т.п.) "забубенить" свой фирменный стиль ввода данных.
Обычно это пара десятков TEdit и разбросанная по нескольким модулям логика обработки доступности полей.

if Mode = 1 {вставка} then
  for i := 0 to ControlCount -1 do
    if Controls[i] is TEdit then
      TEdit(Controls[i]).Enabled := true
...
if fReadOnly then
  for i := 0 to ControlCount -1 do
    if Controls[i] is TEdit then
      TEdit(Controls[i]).Enabled := false;
    ...
if CheckBox1.checked then
begin
  Edit11.Enabled := true;
  Edit12.Enabled := False;
end else
begin
  Edit11.Enabled := False;
  Edit12.Enabled := true;
end;
...
Panel4.Visible := UserName = 'ADMIN';
...
if Edit16.Text = '' then // Поле должно быть заполнено...
if Length(Edit16.Text) > 20 then // Слишком длинно...
if StrToInt(Edit16.Text) then // Блин ввели О вместо 0...
...
  for i := 0 to ControlCount -1 do
    if Controls[i] is TEdit then
      FieldByName(TEdit(Controls[i]).Name).asString := TEdit(Controls[i]).Text;

... ну и так далее, ситуация усугубляется тем, что за сроком давности уж и забыто в каком порядке присваиваются те или иные значения, какие присвоены по ошибке, какие на всякий случай...
В общем я заранне верю, что вы, уважаемые кулхацкеры, круче программистов из Borland, но умоляю используйте dbavare компоненты, управляйте (по возможностьи в одном модуле) доступностью полей (а не Edit`ов) используя свойства TField.ReadOnly, Required и т.п. Очень утомительно рыскать по всем модулям и восхищаться вашей фантазией.

Не, здесь этого, скорее всего, ещё не было.
Это истинный шедевр, я бы его запомнил :)