Как обновлять 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) как быть с разрганичением прав. В рамках единого проекта эти две задачи могут превратиться в трудноразрешимую проблему

← →
sniknik © (2009-02-18 12:06) [29]

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

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

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

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

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

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

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

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

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

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

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

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

← →
Johnmen © (2009-02-18 12:16) [33]

> Может на 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 использовал исключительно.

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

← →
sniknik © (2009-02-18 12:25) [36]

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 отстойная.

← →
sniknik © (2009-02-18 12:40) [39]

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

← →
Ega23 © (2009-02-18 12:45) [40]

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

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

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

Еще раз всем спасибо за внимание.
Хороший у нас формум - добрый и отзывчивый.

← →
Sergey13 © (2009-02-18 13:08) [42]

> [38] тимохов (18.02.09 12:34)
> по теме датабазных компонентов дельфи

ИМХО читать тут надо про клиент-серверную технологию вообще для начала. Т.е. мысленно уходить от модели "взять от базы все и тут покрутить" как можно дальше.
Плюс продумать хорошенько пользовательский интерфейс. ИМХО в принципе направильно давать пользователю ОДНОВРЕМЕННО работать и в справочнике клиентов и в частях приложения, основанных на этом справочнике. MDI придумывался, как мне кажется, для работы с однотипными и НЕЗАВИСИМЫМИ документами. Тот-же ворд например. Для специализированного софта для разнообразной работы с разнообразной и ЗАВИСИМОЙ информацией он подходит очень плохо (исключений думаю не много).

После этого вопрос о конкретных компонентах может и сам собой отпадет.

← →
Sergey13 © (2009-02-18 13:11) [43]

> [42] Sergey13 © (18.02.09 13:08)
> в принципе направильно
в принципе не правильно

← →
Anatoly Podgoretsky © (2009-02-18 13:45) [44]

> тимохов (18.02.2009 9:21:05) [5]

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

Ты для начала освой основы, потом будешь использовать грозные слова.

← →
Anatoly Podgoretsky © (2009-02-18 13:48) [45]

> Плохиш (18.02.2009 10:59:11) [11]

Ни грамма не похож, тот умный.

← →
Anatoly Podgoretsky © (2009-02-18 13:49) [46]

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

TDecimal -> TBCD/TFmtBCD

← →
тимохов (2009-02-18 14:06) [47]

> Anatoly Podgoretsky © (18.02.09 13:49) [46]
>
> > тимохов (18.02.2009 11:11:13) [13]
>
> TDecimal -> TBCD/TFmtBCD

Анатолий, не говори глупостей :) Они ни фига не тоже самое для tdecimal. Особенно в AdoDb.
См. выше, исходники что-ли adodb посмотри, подумай над ними на досуге, QC посмотри насчет багов в той части, а потом пиши на форум.
ок?

-------
Перефразирую, спасибо доброй половине форума, которая сказала действительно полезное.

← →
Плохиш © (2009-02-18 14:07) [48]

> Anatoly Podgoretsky © (18.02.09 13:48) [45]
>
> > Плохиш (18.02.2009 10:59:11) [11]
>
> Ни грамма не похож, тот умный.

Вот и я удивился, а он утверждает, что он...

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

> Sergey13 © (18.02.09 13:08) [42]
>
> > [38] тимохов (18.02.09 12:34)
> > по теме датабазных компонентов дельфи
>
> ИМХО читать тут надо про клиент-серверную технологию вообще

старик, у меня 2 крупных разноплановых проектов от клиент-серверных до распределенных. публичный, правда 1 - www.vkkb.ru. тут, я думаю учиться мне нечему.

твое мнение про MDI мне видится крайне спорным. а что скажешь про 1C - у нее какой интерфейс какой? не MDI случаем?

> тимохов (18.02.2009 14:06:47) [47]

А я говорил, что тоже самое, я тебе показал во что они преобразовываются, особенно в AdoDb.

> тимохов

Возможно это

http://www.devguru.com/Technologies/ado/quickref/recordset_clone.html

тебе поможет.

> твое мнение про MDI мне видится крайне спорным. а что скажешь
> про 1C - у нее какой интерфейс какой? не MDI случаем?

А, типа, 1С - идеал клиентского GUI???

> [49] тимохов (18.02.09 14:13)
> старик, у меня 2 крупных разноплановых проектов от клиент-
> серверных до распределенных

Тогда откуда все эти Table-ы и Filter-ы из которых и растут твои проблемы?

> а что скажешь про 1C

Я не работал с ней, только видел и слышал. Скажу то, что редко какая программа вызывает в инете столько нареканий. У нее есть достоинства, ИМХО, но в другой плоскости.

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

> Sergey13 © (18.02.09 14:59) [53]
> Тогда откуда все эти Table-ы и Filter-ы из которых и растут
> твои проблемы?

краткое содержание пред. серий:
1. в дельфи нет tdecimal (var type 14, почему-то не реализован в дельфи о чем есть соотв. коммент модуле system.pas).
2. поэтому я не пользуюсь его дата контролами и дата аксесом.
3. юзаю свой - импортирован из adodb + своя обертка.
4. также импорт функций работы с tdecimal из oleauto32.dll.
5. посему ни table ни filter ни разу не пользовался.
6. сейчас хочу разбраться, чтобы использовать для простых датабазных задач, которые по ходу бизнеса часто возникают и не являются фундаментальными, чтобы на них писать свои фреймворки - сойдет готовый.

-----

все же по поводу MDI, ты имхо не прав - для систем с большим количеством информации лучше сложно что-то придумать.

>тимохов (18.02.09 14:13) [49]
>> ИМХО читать тут надо про клиент-серверную технологию вообще
>старик, у меня 2 крупных разноплановых проектов от клиент-серверных до распределенных. публичный, правда 1 - www.vkkb.ru. тут, я думаю учиться мне нечему.

"Старик" советует совершенно правильно. Если человек говорит "учиться нечему", это значит человеку остро необходимо учиться и учиться :)

>твое мнение про MDI мне видится крайне спорным.

"Старик" имеет совершенно правильное мнение. Поверье, Вам советую люди, наломавшие лесА этими эмдэишными интерфейсами, а потом переписывывшие проекты заново.

>а что скажешь про 1C - у нее какой интерфейс какой? не MDI случаем?

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

По поводу погрешностей при хранении и вычислении дробных данных.
Опять же на базе весьма немалого опыта советы:

1) числа в БД хранить в формате Float, на клиенте extended
2) иметь в виду адошную хреновую привычку преобразовывать "родное" плавающее в FBCD, борясь с этим явным преобразованием в запросах и получая на клиента ftFloat
3) при любых арифм. операциях НА КАЖДОМ итерационном шаге округлять (чаще всего для денег до сотых копейки - хватает в 99,9 случаев из 100)
4) итоговые суммы по входящим документам (приходам например) должны быть представленны в БД ЯВНО (отдельным полем) и контролироваться при вводе сранением с подсчитанной фактурной.
5) учет ТМЦ вести партионно во избежание получения ненулевого суммового остатка при нулевом количественном, а если все же учет суммовой, то при списании в 0 количества формировать проводку для "сброса" в 0 и суммы - иначе на складе будет туча остатков 0 с ненулеворй суммой - замучаешься с балансировкой, да и с Главной будут расхождения. Особенно это касается "мелочи", например малоценки или материалов типа гвоздей - я этого "добра" в свое время накушался выше крыши, пока не догадался делать правильно и сразу.

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

> MsGuns © (18.02.09 15:08) [55]
> "Старик" советует совершенно правильно. Если человек говорит
> "учиться нечему", это значит человеку остро необходимо учиться
> и учиться :)

виноват, слишком категорично я сказал. исправлюсь. :)

----
У меня как-то особых претензий к MDI интерфейсам нет. Признаться, не видел достойной альтернативы.

----

Тема себестоимости сложна, к сожалению. Особенно в крупных конторах с десятками центров ответственности, внутренними перемещениями и пр. Мы храним и кол-ва, и цены (10 знаков после запятой) и суммы. Пока хватает. На клиент тот самый TDecimal. Кстати, обещают его скоро сделать внутрь дельфи. Тогда точно перейду на native контролы. :)

>тимохов (18.02.09 15:04) [54]
>1. в дельфи нет tdecimal (var type 14, почему-то не реализован в дельфи о чем есть соотв. >коммент модуле system.pas).

А почему - Вы не задумывались ? А главное - зачем ? Типы данных, имеющиеся в Делфи, с лихвой удовлетворяют 100% ЭКОНОМИЧЕСКИХ решений.
К тому же большинство серверов хранят числа с дробями в ПЛАВАЮЩЕМ МАШИННОМ формате, а декларативные типы указывают лишь до какой значности ОКРУГЛЯТЬ числа при расчетах или посылке клиенту.

>2. поэтому я не пользуюсь его дата контролами и дата аксесом.

А вот причем тут датаконтролы и источники - непонятно. Они не связаны с входным преобразованием нативных данных сервера в типы языка, а служат лишь для отображения и привязки.

>5. посему ни table ни filter ни разу не пользовался.

??? Причем тут вообще и то и другое

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

ИМХО, не с того начинаете. Вы еще только-только учитесь ездить на велосипеде, а уже тренируете езду на одном колесе задом наперед (как в цирке)
Что Вы имеете в в иду под "фреймфорком" - что-то типа сервера приложений ?

>все же по поводу MDI, ты имхо не прав - для систем с большим количеством информации лучше >сложно что-то придумать.

MDI придуман вовсе не для "систем с большим количеством информации", а для МНОГОДОКУМЕНТНОЙ системы отображения, советую почитать рекомендации Пачеко на сей счет.
Кроме того, реализовать нормальный МОДАЛЬНЫЙ способ хотя бы для ввода-редактирования, абсолютно необходимый для АДЕКВАТНОГО восприятия технологии работы с приложением БД рядового пользователя, на MDI во-первых сложно технически, во-вторых все равно неудобно, в-третьих все равно будет хуже.

ЗЫ Вы вообще внимательно читаете то, что Вам здесь понаписали ?

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

> MsGuns © (18.02.09 15:22) [57]

мы уже на философию выходим.
к сожалению нет на это времени.
у каждого свои привычки и опыт.

>Тема себестоимости сложна, к сожалению. Особенно в крупных конторах с десятками центров >ответственности, внутренними перемещениями и пр. Мы храним и кол-ва, и цены (10 знаков после >запятой) и суммы. Пока хватает. На клиент тот самый TDecimal. Кстати, обещают его скоро >сделать внутрь дельфи. Тогда точно перейду на native контролы. :)

Сложность только от неопытности - стОить один раз не полениться и сделать правильно :)

Вы опасно заблуждаетесь, считая что если Вам дать аппарат типизации чисел с фиксированной дробью, то "проблема погрешности" будет успешно решена. Не стОит забывать, что один раз "забитая" точность со временем может перестиать удовлетворять учету. И тогда придется лопатить все проекты, переопределяя этот Ваш ftDecimal. Который, повторюсь, нужен как ужу рогатка.

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

> MsGuns © (18.02.09 15:30) [59]

да, отказать подискутировать сложно :)

Согласитесь, что все в мире относительно. в том числе и правильность. в бухучете вообще правильность не ясна - многие вопросы ни в ПБУ ни в других документах не рассмотрены или рассмотрены поверхностно. Особенно это касается алгоритмов. Все делают в меру своего понимания. А понимание у всех тоже разное.

К тому же никакой связи себестоимости и Decimal я не делал. Я просто сказал, что использую Decimal для хранения себестоимости.

Погрешности всегда бывают. На это есть учетная политика предприятия, которая прописывает приемлемость их в том или ином виде.

>тимохов (18.02.09 15:34) [60]

>правильность не ясна - многие вопросы ни в ПБУ ни в других документах не рассмотрены или >рассмотрены поверхностно. Особенно это касается алгоритмов. Все делают в меру своего >понимания. А понимание у всех тоже разное.

Вы не правы. В БУХГАЛТЕРСКОМ УЧЕТЕ все предельно ясно, в частности с округлением, которое у него отличается от математического. Туманность и неоднозначность имеется в НАЛОГОВОМ УЧЕТЕ, хотя бы потому, что он перманентно изменяется. Но не в сторону правл округления однако :)

>К тому же никакой связи себестоимости и Decimal я не делал. Я просто сказал, что использую >Decimal для хранения себестоимости.

Опять Вы невнимательно читаете. Этот самый DECIMAL суть ПРАВИЛО ЯЗЫКА, в данном случае принятым в конкретным стандарте сиквеля. В одном стандарте он есть, в другом его может не быть - жестко привязывать логику клиентского приложения к каким бы то ни было стандартам скл-серверов - это рыть себе ямы и в их дно вколачивать заостренные колья, чтобы "мягче" было падать :)

Погрешности всегда бывают. На это есть учетная политика предприятия, которая прописывает приемлемость их в том или ином виде.

>да, отказать подискутировать сложно :)

Да Бога ради. Стучитесь о свои столбы самостоятельно :)

Примите и проч.

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

Фраза

>Погрешности всегда бывают. На это есть учетная политика предприятия, которая прописывает >приемлемость их в том или ином виде.

затесалась ошибочно - она не моя :)

Напоследок:

ИМХО, у Вас все в куче: MDI, типы данных, ADO, Delphi, фрэймворки.. Некоторый (возможно немалый) опыт программирования у Вас имеется очевидно, но.. Не поддавайтесь соблазну (и всяким Фароновым) и не думайте, что профессионально проектировать "базовые" системы просто - поверьте - очень непросто !

Короче, ДИма. Завтра тут мини-сбор намечается. Ежели есть желание - подтягивайся, "на пальцах" что я, что Петро рассказать много смогем. :)

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

> Ega23 © (18.02.09 15:51) [64]
>
> Короче, ДИма. Завтра тут мини-сбор намечается. Ежели есть
> желание - подтягивайся, "на пальцах" что я, что Петро рассказать
> много смогем. :)

да не надо, сам разберусь :) я захотел ощутить себя в шкуре вопрошающего. резюме - получить полезный ответ можно, но потерпеть придется :)

напиши куда подтягивацо на timokhov................... gmail......................com

всем спасибо. не пошел не фаронова читать.

Отправил.

> тимохов (18.02.2009 15:49:02) [62]

Мы тут больше по программированию, в своей предметной области.

> Ega23 (18.02.2009 15:51:04) [64]

Так это все таки наш Сусликов :-)

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

Да я это я :)

Отвык немного от общения в форумах. Занят был. Так что извиняйте, если что не так. Один проект заканчивал (тот самый публичный), второй расконсервировал (тот где TDecimal). Сейчас учетку пишу публичного проекта.

Вот! Надо будет еще у Кенту посмотреть что-то - он любитель делать платные электронные книги, может там есть курс молодого бойца.

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