Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 4 >
тимохов © (2009-02-18 08:58:00)
Здравствуйте!

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

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

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

sniknik (2009-02-18 12:06:00) [41]
> Я искренне не понимаю, нафига точность до десятимиллионной копейки.
такая фигня была постоянно когда цены держатся в долларах/(счас еще наверно евро), а учет/отчеты в рублях... и хочется чтобы сходилось...

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

MsGuns (2009-02-18 12:05:00) [42]
>тимохов (18.02.09 11:11) [13]
>3) Чем адодатасет лучше?

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

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

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

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

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

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

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

Ega23 (2009-02-18 11:58:00) [43]

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

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

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

Ega23 (2009-02-18 11:55:00) [44]

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

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

sniknik (2009-02-18 11:54:00) [45]
> Вот я и спрашиваю, что есть нормально :)
удалить из палитры 3 компонента TAdoTable, TAdoQuery, TAdoStoredProc, и пользоваться тем что осталось. вот это нормально.

тимохов (2009-02-18 11:52:00) [46]

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

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

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

sniknik (2009-02-18 11:51:00) [47]
> как вообще люди пишут, разрабатывая финансовые системы на дельфи
нормально пишут... пользуемся типом "деньги" (моней/каренси, где как называются) с 4мя фиксированными цифрами после запятой... хватает.

тимохов (2009-02-18 11:49:00) [48]

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

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

Ega23 (2009-02-18 11:49:00) [49]

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

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

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

тимохов (2009-02-18 11:42:00) [51]

> 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-клиентам?

Ega23 (2009-02-18 11:39:00) [52]

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

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

Виталий Панасенко (2009-02-18 11:37:00) [53]
А в OnDelete/OnPost мастера LookupRefresh почему не вызвать?

тимохов (2009-02-18 11:25:00) [54]
Вот оно:

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:20:00) [55]

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

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

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

Ega23 (2009-02-18 11:15:00) [56]

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

TBCDField ?

тимохов (2009-02-18 11:11:00) [57]

> 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:05:00) [58]

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

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

Плохиш (2009-02-18 10:59:00) [59]
Я сильно надеюсь, что это не суслик...

Ega23 (2009-02-18 10:56:00) [60]

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

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

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »