Как обновлять TAdoTable в одной форме, при изменении в другой?

← →
тимохов (2009-02-18 08:58) [0]

Здравствуйте!

Есть 2 MdiChild формы.
На каждой по TAdoTable, смотрящих на одну и ту же таблицу в БД.

Требуется при изменении таблицы в одной форме как-то обновить TAdoTable в другой форме.

Какой для этого у Дельфи существует стандартное решение?
Если нет, то кто как делает в подобных случаях?

← →
Anatoly Podgoretsky © (2009-02-18 09:08) [1]

> тимохов (18.02.2009 8:58:00) [0]

Refresh

← →
MsGuns © (2009-02-18 09:10) [2]

Ламерский:

Unit FormChild1

uses Unit2

FormChid2.ADOTable1.ReQuery

Джидайский: послать сообщение и в Unit2 "отреагировать", переоткрыв датасет

ЗЫ. ИМХО, две концептуальные ошибки:

1) Не следует без крайней нужды "дергать" датасеты неактивных форм
2) Использование компонента TADOTable

и один вопрос: кавова необходимость в MDI ?

← →
Медвежонок Пятачок © (2009-02-18 09:12) [3]

После сделанных изменений - сообщение из дочерней в главную.
из главной трансляция полученного сообщения всем чайлдам.
при получении сообщения в чайлде делать
Requery

ну и заменить все адотэйбл\адоквери на адодатасет

← →
MsGuns © (2009-02-18 09:19) [4]

>Медвежонок Пятачок © (18.02.09 09:12) [3]

Ты знал ! :)

← →
тимохов (2009-02-18 09:21) [5]

1) Несмотря на мой опыт в разработке клиентов для баз данных на дельфи я первый раз пользуюсь датабазными компонентами от дельфи :) Решил использовать их для базы, ориентированной на ввод информации о клиентах. Посему и вопросы такие, ламерские :)

2) Ок. Я понял, нужно самому рассылать сообщения. Я думал, что может, если у TAdoTable один TAdoConnetion, то таблицы сами разберутся что к чему.

3) Чем адодатасет лучше?

4)

MsGuns © (18.02.09 09:10) [2]

1) Не следует без крайней нужды "дергать" датасеты неактивных форм
2) Использование компонента TADOTable

Дело в том, что в одной форме у меня заводится информация о клиентах, в другой - используется та же таблица как Lookup, для вставки клиентов в другую таблицу. Сейчас получается, что ввел клиента, а он не виден в другой таблице. Приходится форму открывать и закрывать.

и один вопрос: кавова необходимость в MDI ?
Я вообще планирую данную систему развивать долго и поглотить все наши учетные задачи по работе с клиентами. Своего рода - это доморощенная CRM система будет, учитывающая специфику взаимодействия с клиентами. Посему MDI нужен - куда еще 30 форм деть?

← →
Sergey13 © (2009-02-18 09:46) [6]

> [5] тимохов (18.02.09 09:21)
> и поглотить все наши учетные задачи по работе с клиентами

Громадье планов! 8-)

> Посему MDI нужен - куда еще 30 форм деть?

Почему посему? Потому что планов громадье и боишься просто забыть про некоторые формы?

← →
sniknik © (2009-02-18 10:34) [7]

> Какой для этого у Дельфи существует стандартное решение?
датамодуль с ОДНИМ датасетом, а визуальные компоненты с обоих форм должны "смотреть" в общий датасоурс в том же датамодуле.

← →
Ega23 © (2009-02-18 10:35) [8]

> Посему MDI нужен - куда еще 30 форм деть?

Берёшь TPageControl, делаешь 30 вкладок, на каждую - свой фрейм. Общие дб-шные компоненты выносишь в датамодуль, частные (кроме конкретного фрейма нигде не нужные) - на конкретный фрейм.
Для удобства вообще создаёшь базовый фрейм и от него наследуешь все остальные.

Собственно, всё.

← →
тимохов (2009-02-18 10:44) [9]

> sniknik © (18.02.09 10:34) [7]
>
> > Какой для этого у Дельфи существует стандартное решение?
>
> датамодуль с ОДНИМ датасетом, а визуальные компоненты с
> обоих форм должны "смотреть" в общий датасоурс в том же
> датам

Была такая идея у меня. Но я используют фильтрацию, т.е. Filtered. Причем теоретически на разных формах свои правила фильтрации. Т.е. один датасет не подходит :(

Датамодуль я сделал - у меня там TAdoConneсtion лежит.

------------
Вообще, какой сейчас по теме мейнстримовый учебник? У меня есть Кен Хендерсон от Дельфи 3, но я так понял, что он устарел уже сильно.

← →
Ega23 © (2009-02-18 10:56) [10]

> Была такая идея у меня. Но я используют фильтрацию, т.е.
> Filtered. Причем теоретически на разных формах свои правила
> фильтрации.

Ну и делай свой датасет на каждую форму.
Откровенно говоря, я у себя не припомню, чтобы 2 DB-контрола с разных форм ссылались на один НД.

← →
Плохиш © (2009-02-18 10:59) [11]

Я сильно надеюсь, что это не суслик...

← →
Ega23 © (2009-02-18 11:05) [12]

> Я сильно надеюсь, что это не суслик...

Зря надеешься.

← →
тимохов (2009-02-18 11:11) [13]

> Ega23 © (18.02.09 10:56) [10]
>
> Ну и делай свой датасет на каждую форму.

Ну так и делаю

> Откровенно говоря, я у себя не припомню, чтобы 2 DB-контрола
> с разных форм ссылались на один НД.

Что здесь такого? На одной форме редактируется таблица (плюс еще фильтроваться может), в другой форме используется как lookup. Есесно во второй форме результаты фильтрации в первой форме не нужны - нужен результат заведения данных.

Ок. Я в общем понял, что нужно ручками обновлять.

> Плохиш © (18.02.09 10:59) [11]
> Я сильно надеюсь, что это не суслик...

Это именно я... Видимо тебя удивило мое незнание стандартной библиотеки дельфи? Вот когда сделают они в своих датасетах родной TDecimal (см. репорты http://qc.codegear.com/wc/qcmain.aspx?d=28022 или http://qc.codegear.com/wc/qcmain.aspx?d=3474), а не ублюдочное преобразование TDecimal в Extended при чтении из БД, тады и буду пользоваться датасетами и соответственно изучать их. А пока для разработки своей финансово-учетной системы как пользовался своими наработками так и буду пользоваться.

Для задач, где информация преимущественно текстовая датасеты, видимо подходят неплохо. Вот я и решил изучать :)

← →
Ega23 © (2009-02-18 11:15) [14]

> Вот когда сделают они в своих датасетах родной TDecimal

TBCDField ?

← →
тимохов (2009-02-18 11:20) [15]

> Ega23 © (18.02.09 11:15) [14]
> > Вот когда сделают они в своих датасетах родной TDecimal
> TBCDField ?

Скажи, а ты сам то им пользовался для работы с типом T-SQL decimal(28,10)?

ЗЫ. Прошу у модераторов прощения, что дискуссия получается немного офтоповая. Но все бывает - может я выясню сейчас, что decimal(28,10) - это никакая не проблема для rich-клиентов на Дельфи.

← →
тимохов (2009-02-18 11:25) [16]

Вот оно:

function ADOTypeToFieldType(...): TFieldType; begin case ADOType of ... adDecimal, adNumeric, adVarNumeric: if EnableBCD then Result := ftBCD else Result := ftFloat; else Result := ftUnknown; end; end;

и далее по тексту ftBCD приравнивается к Currency. Блин.

Вот чего им стоило использовать VarDecAdd из oleaut32.dll? Я уже ими пользуюсь лет 9. Сейчас вообще хорошо стало, когда перегрузка операторов появилась. Зато типа TDecimal родной, а не замена Currency с потерей точности.

← →
Виталий Панасенко (2009-02-18 11:37) [17]

А в OnDelete/OnPost мастера LookupRefresh почему не вызвать?

← →
Ega23 © (2009-02-18 11:39) [18]

> Скажи, а ты сам то им пользовался для работы с типом T-SQL
> decimal(28,10)?

Н-да, забавно... Не, я же не по финансовой части... :) У нас и numeric использовался всего один раз
Set @Date=cast( Floor(cast(@DateTime as numeric(18,12))) as datetime)

← →
тимохов (2009-02-18 11:42) [19]

> Ega23 © (18.02.09 11:39) [18]
>
>
> > Скажи, а ты сам то им пользовался для работы с типом T-
> SQL
> > decimal(28,10)?
>
>
> Н-да, забавно... Не, я же не по финансовой части... :)
> У нас и numeric использовался всего один раз
> Set @Date=cast( Floor(cast(@DateTime as numeric(18,12)))
> as datetime)

Забавно то, что интересно как вообще люди пишут, разрабатывая финансовые системы на дельфи. Понятно, что если делать ислючительно тонкого клиента, то можно и преобразовать decima(28,10) в float и отображать. А если какие-то арифметические действия нужно делать? Или смерть rich-клиентам?

← →
sniknik © (2009-02-18 11:47) [20]

> Но я используют фильтрацию, т.е. Filtered.
ну и зря... пользовался бы нормальными компонентами и запросами, проблемы не возникло бы. (а сколько еще в будущем предстоит...)

← →
Ega23 © (2009-02-18 11:49) [21]

> Забавно то, что интересно как вообще люди пишут, разрабатывая
> финансовые системы на дельфи. Понятно, что если делать ислючительно
> тонкого клиента, то можно и преобразовать decima(28,10)
> в float и отображать. А если какие-то арифметические действия
> нужно делать? Или смерть rich-клиентам?

Подожди, но в финансовой сфере точность разве не до 4-го знака идёт? (я просто не в теме, но что-то такое слыша краем уха).
10 после запятой - это выше моего понимания.

← →
тимохов (2009-02-18 11:49) [22]

> sniknik © (18.02.09 11:47) [20]
>
> > Но я используют фильтрацию, т.е. Filtered.
> ну и зря... пользовался бы нормальными компонентами и запросами,
> проблемы не возникло бы. (а сколько еще в будущем предстоит.
> ..)

Вот я и спрашиваю, что есть нормально :)
Должны быть какие-то бест-практиз из области использования дельфовых компонентов?

← →
sniknik © (2009-02-18 11:51) [23]

> как вообще люди пишут, разрабатывая финансовые системы на дельфи
нормально пишут... пользуемся типом "деньги" (моней/каренси, где как называются) с 4мя фиксированными цифрами после запятой... хватает.

← →
тимохов (2009-02-18 11:52) [24]

> Ega23 © (18.02.09 11:49) [21]
>
> Подожди, но в финансовой сфере точность разве не до 4-го
> знака идёт? (я просто не в теме, но что-то такое слыша краем
> уха).
> 10 после запятой - это выше моего понимания.

ты не забыл, что есть еще арифметические операции? умножение, деление? Или предлагаешь на каждом шаге до 4 знаков обрезать? А учетные цены чем предлагаешь хранить? Там точность нужна, чем больше, тем лучше. Может на float перейти? Тогда в ходе арифметических вычислений все приводить к float? Потом иметь проблемы, присущие числам с плавающей точкой?

во общем - без TDecimal жить не хочу :)

← →
sniknik © (2009-02-18 11:54) [25]

> Вот я и спрашиваю, что есть нормально :)
удалить из палитры 3 компонента TAdoTable, TAdoQuery, TAdoStoredProc, и пользоваться тем что осталось. вот это нормально.

← →
Ega23 © (2009-02-18 11:55) [26]

> Или предлагаешь на каждом шаге до 4 знаков обрезать?

Ну, вопщем да... Я искренне не понимаю, нафига точность до десятимиллионной копейки.

← →
Ega23 © (2009-02-18 11:58) [27]

> Ну, вопщем да... Я искренне не понимаю, нафига точность
> до десятимиллионной копейки.

Ну либо арифметику на сервере делать с высокой точностью, а при финальном селекте - кастовать к удобоваримому типу.
В конце-концов, любую ниформацию всегда через стринг можно передать, а уж потом её преобразовать так, как тебе надо.
Не вижу причин отказываться ради одного несчастного поля от Native-компонентов.

Хтя это моё ичное ИМХО.

← →
MsGuns © (2009-02-18 12:05) [28]

>тимохов (18.02.09 11:11) [13]
>3) Чем адодатасет лучше?

Много чем. Например, не тянет все данные, а только нужные, позволяя "фильтровать" информацию непосредственно на сервере, разгружая сеть и клиентский ПК также от лишних (не нужных в данный момент) данных. А также удобство сортировок и много еще чего.

>Дело в том, что в одной форме у меня заводится информация о клиентах, в другой - >используется та же таблица как Lookup, для вставки клиентов в другую таблицу.

Не лучшее решение. Вместо лукапа, возможности которого крайне ограничены, использовать форму отображения справочника, показываемую модально. Если нужно добавление (правка) "на лету", предусмотреть модальный вызов из этой формы другую типа "карточка партнера", где и вводить поля нового или редактируемого партнера. Форма справочника много предпочтительнее лукапа потому, что обладает всеми "вкусностями": поиск, сортировки, фильтрации, а также показывает ВСЕ поля, а не только одно, как в лукапе. После внесения изменений модифицированную таблицу автоматически перечитывать (именно перечитывать, а не рефрешить !) с позиционированием на новой (измененной) записи

>Сейчас получается, что ввел клиента, а он не виден в другой таблице. Приходится форму >открывать и закрывать.

При описанной выше технологии автоматически отпадает

>Я вообще планирую данную систему развивать долго и поглотить все наши учетные задачи по >работе с клиентами. Своего рода - это доморощенная CRM система будет, учитывающая >специфику взаимодействия с клиентами. Посему MDI нужен - куда еще 30 форм деть?

Следует продумать при проектировании такого многофункционала такую вещь: со временем кол-во пользователе может возрасти, а их специфика - сузиться и неизбежно встанет 2 вопроса: 1) зачем конкретному пользователю "лишние" формы и 2) как быть с разрганичением прав. В рамках единого проекта эти две задачи могут превратиться в трудноразрешимую проблему

> Я искренне не понимаю, нафига точность до десятимиллионной копейки.
такая фигня была постоянно когда цены держатся в долларах/(счас еще наверно евро), а учет/отчеты в рублях... и хочется чтобы сходилось...

> а при финальном селекте - кастовать к удобоваримому типу.
а потом бухгалтер берет накладную/отчет складывает столбиком все цифры проверяя сумму и...... "где копейка. я вас спрашиваю? это документ! тут все должно до копеек сходится!"

> тимохов (18.02.09 11:11) [13]

> Это именно я... Видимо тебя удивило мое незнание стандартной
> библиотеки дельфи?

Меня не это удивило, а отсутствие логики. К тому же эта тема многократно мусолилась на форуме, правда раньше эти темы сразу же отправляли в "начинающим".

> а потом бухгалтер берет накладную/отчет складывает столбиком
> все цифры проверяя сумму и...... "где копейка. я вас спрашиваю?
> это документ! тут все должно до копеек сходится!"
>

select Numb=cast(Numb as varchar(30)) from test Numb ------------------------------ 999999999999999999.9999999999 888888888888888888.8888888888 777777777777777777.7777777777 666666666666666666.6666666666 (4 row(s) affected)

Вместо лукапа, возможности которого крайне ограничены, использовать форму отображения справочника, показываемую модально. Если нужно добавление (правка) "на лету", предусмотреть модальный вызов из этой формы другую типа "карточка партнера", где и вводить поля нового или редактируемого партнера. Форма справочника много предпочтительнее лукапа потому, что обладает всеми "вкусностями": поиск, сортировки, фильтрации, а также показывает ВСЕ поля, а не только одно, как в лукапе. После внесения изменений модифицированную таблицу автоматически перечитывать (именно перечитывать, а не рефрешить !) с позиционированием на новой (измененной) записи

Ну да, в целом согласен. Как-то так и делаю обычно.

> Может на float перейти?

На DOUBLE PRECISION.

> Потом иметь проблемы, присущие числам с плавающей точкой?

Какие конкретно?

← →
тимохов (2009-02-18 12:17) [34]

> MsGuns © (18.02.09 12:05) [28]

Спасибо за лекцию. Буду думать.

Вообще, если у меня станет серьезная задача развивать CRM я перепишу ее в своем существующим frame-work"е, который неплохо продуман для разработки и последующей поддержки (на нем крутится 50 инсталляций с 100 юзерами в каждой - бухгалтерами, финансистами, МСФОошниками и кучей другого народа, данных до 10млн сущностей) но не обладает возможность быстрого создания прототипов: если уж сел делать, то делай хорошо и сразу. А дельфи, видимо, неплох для создания прототипов. Поэтому, от native датабазных контролов дельфи мне нужен минимальный набор функциональности - лишь бы идея базы была понятна.

← →
тимохов (2009-02-18 12:23) [35]

> Johnmen © (18.02.09 12:16) [33]
> > Потом иметь проблемы, присущие числам с плавающей точкой?
> Какие конкретно?

Сравнивать равенством. Нельзя же. Ну и прочие недостатки, описанные в небезызвестной статье Антона Григорьева. Скажу честно, что я не пользовался флоатами уже лет 7 - когда они меня в первый раз разочаровали, я еще "зеленый" был, возможно, что с теперешним опытом я бы лучше к ним стал относиться. С тех пор TDecimal использовал исключительно.

------
Господа, всем спасибо за внимание. Пойду почитаю что-нибудь :)

Ega23 © (18.02.09 12:10) [31]
и??? чего то не понял к чему это.

или, не я не понял...
ну ладно давай возьмет твои цифры, для примера немного упростим, т.к. смысл показать не проблему переполнения, а проблему разрыва хранения с отображением.
пусть ты хранишь так, и считаешь соответственно,
9.9999999999
8.8888888888
7.7777777777
6.6666666666
сумма
33,333333333
но в документе "удобоваримой" будет округление до 2 цифр (максимум 3, больше не видел) после запятой, т.е. документ будет вида
10.00
8.89
7.78
6.67
сумма
33.33

а ручная проверка даст 33,34 ... где копейка? и объясняй это не мне , а бухгалтеру...

← →
тимохов (2009-02-18 12:28) [37]

> sniknik © (18.02.09 12:25) [36]

Проблема копейки вообще не разрешима.
Ее только договоренностями можно решать.

Опять же - в учетную политику предприятия можно прописать.

← →
тимохов (2009-02-18 12:34) [38]

Все же остался вопрос - что почитать такого полезного по теме датабазных компонентов дельфи? Что есть такое узкоспециализированное?

К справке не относите - она у Delphi2007 отстойная.

> Проблема копейки вообще не разрешима.
??? а почему бы не считать также как это делает бухгалтер руками (т.е. с тем же округлением), так как в документ выводится. а чтобы не "рвало" с другими отчетами, то и хранить в той же форме, приводя результаты вычислений к такому же виду...
естественно в таком случае будет не стыковка "в общем" на результат округлений, но он в общем будет меньше т.к. часть "плюсовых округлений" поглотится "минусовыми" из других расчетов...
(кстати очень похоже на банковское округление. почитай если интересно).

> Все же остался вопрос - что почитать такого полезного по
> теме датабазных компонентов дельфи? Что есть такое узкоспециализированное?

На sql.ru и на rsdn посмотри статьи, вроде неплохие были.
Сам тоже всё собираюсь Getting Started написать, да руки никак не доходят.

Как обновлять TAdoTable в одной форме, при изменении в другой? Найти похожие ветки