Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Delphi Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 52   вперед  Ctrl
 Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
Dmitry Arefiev
Member

Откуда:
Сообщений: 9664
Привет

Обращаюсь, к Delphi разработчикам с, собственно, subj. Мы делаем версию 2, и сейчас принимаются к рассмотрению все фичи реквесты, идеи, и просто коментарии.

Удачи,
Дмитрий

--
AnyDAC (www.da-soft.com) - быстрый прямой доступ к Oracle, MySQL, MSSQL,
MSAccess, IBM DB2, Advantage DS, Sybase ASA, DbExpress, ODBC.
19 май 07, 18:56    [4159740]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
Dmitry Arefiev
Привет

Обращаюсь, к Delphi разработчикам с, собственно, subj. Мы делаем версию 2, и сейчас принимаются к рассмотрению все фичи реквесты, идеи, и просто коментарии.

Удачи,
Дмитрий

--
AnyDAC (www.da-soft.com) - быстрый прямой доступ к Oracle, MySQL, MSSQL,
MSAccess, IBM DB2, Advantage DS, Sybase ASA, DbExpress, ODBC.


Безболезненная миграция с ODAC, dbGo и BDE. В один клик ;)
19 май 07, 19:32    [4159768]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 49209
Чтобы была гарантия, что ни на что больше не придётся переходить
19 май 07, 19:55    [4159782]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
Dmitry Arefiev
Member

Откуда:
Сообщений: 9664
andreymx
Чтобы была гарантия, что ни на что больше не придётся переходить

Это вопрос про удовлетворение ваших требований. Каковы они ?
19 май 07, 20:30    [4159807]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54542
Блог
Dmitry Arefiev
Обращаюсь, к Delphi разработчикам с, собственно, subj.

Наличие каких-либо весомых преимуществ перед ODAC. Точнее, убедительный ответ на вопрос "что хорошего я получу, сделав этот переход".
19 май 07, 21:35    [4159854]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
Dmitry Arefiev
Member

Откуда:
Сообщений: 9664
softwarer
"что хорошего я получу, сделав этот переход".

Я не знаю - чего вы хотите, что и как вы делаете. Точное формулирование ваших требований станет тем лучшем дл меня, на основании чего я смогу сделать выводы и предложить вам будущие стандартные решения AnyDAC. Примерно так ...
19 май 07, 22:39    [4159908]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54542
Блог
Дим, я понимаю. Проблема в том, что ODAC меня практически полностью устраивает - у меня конечно есть собственные доработки, но это не уровень "выдвигайте требования", так, разного рода удобства. Поэтому позиция выходит "а ради чего собственно мне искать добра от добра?" - я понимаю, что такой ответ не очень удачен для вас, но тем не менее, именно таков он у меня (и, думаю, не только у меня).

Скажем, одна из тех доработок, которые я сделал - в компонент Session добавлены два списка макросов (обычные ODAC-овские TMacro, те, что в запросах). Эти макросы автоматически применяются к любому Query, связанному с этим Session - то есть мне не нужно в каждом Query специально инициализировать одни и те же "стандартные" значения, они автоматом подставляются из session-wide списка. Списков два потому, что один из них - просто задаваемый приложением набор переменных, а вот другой представляет собой результат парсинга package-ей из схемы приложения. Таким образом я получаю возможность использовать на клиенте константы, определенные в серверной части - я пишу что-нибудь типа

select .... where type_id = &type_superpuper and .... 

и сюда подставляется значение, полученное из

create package Common$Const as

  type_superpuper constant integer := 1 ;
  ....
end ;

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

Писали мы инсталлятор. У инсталлятора, что вполне естественно, есть набор параметров - те самые session-wide переменные, например "название tablespace". И вот тут получается засада: в некоторых случаях нам нужно употребить этот параметр как синтаксический элемент, в других - как часть текстовой константы, скажем

create tablespace &Tablespace datafile '&Tablespace.dbf' ....

И вот именно здесь ODAC показал себя с не лучшей стороны.
19 май 07, 23:03    [4159929]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
Dmitry Arefiev
Member

Откуда:
Сообщений: 9664
softwarer
Проблема в том, что ODAC меня практически полностью устраивает

Я это прекрасно понимаю, но готов бороться за пользователей и предлагать им то, что не было найдено в готовом виде и что может быть ценным для остальных.
softwarer
"а ради чего собственно мне искать добра от добра?"

Согласен. Но я готов рассматривать и реализовывать хорошие идеи. Возможно, однажды появится смысл ...
softwarer
в компонент Session добавлены два списка макросов

Разумно - принято.

Удачи,
Дмитрий
19 май 07, 23:16    [4159937]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
softwarer
Dmitry Arefiev
Обращаюсь, к Delphi разработчикам с, собственно, subj.

Наличие каких-либо весомых преимуществ перед ODAC. Точнее, убедительный ответ на вопрос "что хорошего я получу, сделав этот переход".


Смотря с какой версии ODAC, кстати. Если с 5-ки, то достаточно много, с 6-ки - список решительно сокращается (к примеру, CoreLab порешала вопросы с LargeInt, DML по всем полям, statement cache (правда не досмотрел, на каком уровне), где то пофиксила производительность, поломав при этом кой чего (к примеру "обновляемость" CONNECT BY и UNION ALL запросов). Такое ощущение, что тщательно изучив одну из наших "чайных" посиделок (на этот счет)).

Но в целом AnyDAC как то IMHO, более... кхм, разумен в удовлетворении потребностей возможностями, да и саппорт таки чуть порасторопнее ;))

Если бы г-н Арефьев еще и огрызки-акронимы переделал и сделал бы утилиту миграции (некоторым актуально) ;)), то.. ODAC бы окончательно (у меня) полетел бы в корзину...

Впрочем, пока я жду обещанных профилей дейтасетов и detachable модели (или уже сделано?) т.к. портировать свои нет времени, да и смысла, уже
19 май 07, 23:20    [4159941]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
Dmitry Arefiev

softwarer
в компонент Session добавлены два списка макросов

Разумно - принято.

Удачи,
Дмитрий


&global.substitution_name?

А почему бы тогда не доделать уже и нечто вида:

:global.param_name?

И для пущего удовольствия, нечто вроде:

:form_name.dataset_name.field_name
:dataset_name.field_name

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

Естественно, при фактическом выполнении делая соответствующие преобразования (ибо Oracle точку в параметре уж точно не примет).
19 май 07, 23:27    [4159945]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54542
Блог
grexhide
А почему бы тогда не доделать уже и нечто вида:
:global.param_name?

Лично мне такое не требовалось. Если постараться, наверное, можно придумать задачу, какой-нибудь "текущий выбранный отчетный период", но редко, редко, и обычно делается переменными на сервере и/или контекстом.

grexhide
И для пущего удовольствия, нечто вроде:
:form_name.dataset_name.field_name
:dataset_name.field_name

Крайне сомнительная мысль, имхо, особенно первое. Прокладывание крайне ненадежной динамической связи, нарушающей все принципы модульности. Эдак получается, что решив переименовать датасет, я должен буду запустить глобальный поиск - а не используется ли случаем где-нибудь параметр, вытаскиваемый из этого датасета?
20 май 07, 00:27    [4159991]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
softwarer
grexhide
А почему бы тогда не доделать уже и нечто вида:
:global.param_name?

Лично мне такое не требовалось. Если постараться, наверное, можно придумать задачу, какой-нибудь "текущий выбранный отчетный период", но редко, редко, и обычно делается переменными на сервере и/или контекстом.

С таким же успехом константы-макросы можно вызывать напрямую (пусть и через функции-обертки, или контексты (которые чуть быстрее первых)). В случае WHERE - это не несёт особых трудностей, т.к. вызов будет делаться лишь один раз (в отличии от SELECT - где контекст будет долбиться на каждую строку выборки)).

Если, конечно, не важны аспекты стоимостного оптимизатора от.. гистограмм и прочих вещей, завязанных на явные значения (OLTP vs DSS).

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

К примеру:

1. Есть генератор констант из таблиц (ищем CONST_NAME, VALUE в USER_TAB_COLUMNS)
2. Генератор продуцирует пакеты (с MY_CONST_NAME const := ;MY_CONST_NAME$ function
+ инициализации контекстов

3. На клиенте мы вольны использовать или PCONSTS.MY_CONST_NAME$ (в данном случае будет произведена замена на SYS_CONTEXT) или же - PCONSTS.MY_CONST_NAME# (в занном случае будет выполнено "прямая" замена на значение константы).

Т.е. глобальные макросы... И вовсе не нужны (и даже вредны - т.к. они глобальные, пусть и в пределах сессии, т.к. есть еще и вложенности, и пользовательские фильтры и масса других, потенциально конфликтных мест).

softwarer

grexhide
И для пущего удовольствия, нечто вроде:
:form_name.dataset_name.field_name
:dataset_name.field_name

Крайне сомнительная мысль, имхо, особенно первое. Прокладывание крайне ненадежной динамической связи, нарушающей все принципы модульности. Эдак получается, что решив переименовать датасет, я должен буду запустить глобальный поиск - а не используется ли случаем где-нибудь параметр, вытаскиваемый из этого датасета?



1. Ну... тут у каждого религия строго своя. К примеру - я использую только следующие имена дейтасетов:

Q
Data
MasterData
DetailData

Т.е. строго от типологии форм.

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

2. Глобальный поиск, в том числе по формам (GExperts) - это дело плевое, на самом деле. Впрочем, аспекты глобальной валидации дейтасетов (выполняемость, вернее препарируемость курсоров, в виде эдакой компиляции) - это совсем отдельный аспект (и как его решить разумным способом в общем случае... это еще тот вопрос).

3. Тем не менее, идея эта - не нова, и даже вовсе не идея - лишь попытка получить примерно тоже самое, что мы имеем (кхм, возможность наблюдать) в случае Oracle Forms
20 май 07, 00:47    [4159999]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
:form_name.dataset_name.field_name


softwarer

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


Во первых нет (второй случай).

Я нахожу весьма удобным примерно следующее:

DBComboBox.LookupSQL := 'SELECT * FROM C_CONTRACTS WHERE CLIENT_ID = :CLIENT_ID'

Суть примерно понятна - ComboBox выводит список договоров (их не больше десятка, обычно) для текущего контрагента текущего (для DBComboBox) дейтасета (LookupSQL - такого нет в VCL и.. практически нигде, кроме, пожалуй FoxPro, если не изменяет память).


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

И вот тут да, "неправильная" модульность довольно лихо заканчивается на том аспекте, что нам нужно указать (ограничить) видимость форм (от их имен). Т.е. мы можем обходить или Screen.Forms (что действительно, довольно сомнительно (мягко говоря) в случае MDI, но вполне приемлимо в случае SDI), либо же - поступать более логично (злостно правя DAC) - изобретать эдакий контекст, в котором будет действительно form_name зарегистрирован, к примеру, как алиас на физическую форму с .Name = 'form_name_4' (четвертый инстанс класса TForm_Name в случае MDI).
20 май 07, 01:00    [4160002]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54542
Блог
grexhide
С таким же успехом константы-макросы можно вызывать напрямую

Можно. Но неудобно.

Исторически первое, для чего я реализовал этот механизм - это для подстановки значения в запросы вида

select
...
from &Schema.T1 T1, &Schema.T2 T2, ....

Далее это оказалось удобно и для констант (через макросы, а не через параметры - потому что в запросах как правило используется именно одно конкретное значение).

grexhide
Впрочем, идею глобальных макросов я бы не назвал сильно удачной (в случае именно констант):

Автогенератор - хуже, имхо. Как и любая денормализация, это то, за чем нужно специально следить. Выполнив запрос сразу после соединения, я получаю гарантированно актуальный результат; в Вашем варианте мне приходится верить в то, что Вася не забыл запустить генератор после того, как поправил перепутанные им значения констант А и Б.

grexhide
Т.е. глобальные макросы... И вовсе не нужны (и даже вредны - т.к. они глобальные, пусть и в пределах сессии, т.к. есть еще и вложенности, и пользовательские фильтры и масса других, потенциально конфликтных мест).

Прошу прощения, если не понял всей глубины мысли, но для меня это выглядит бессмысленным набором слов. Я не увидел ни одного аргумента, такое впечатление, что просто реакция на самопридуманное Вами слово "глобальный" (причем от человека, который, по всей видимости, пользуется глобальными переменными Application, Screen итп, и вряд ли сильно страдает от этого).

grexhide

1. Ну... тут у каждого религия строго своя. К примеру - я использую только следующие имена дейтасетов:

Q
Data
MasterData
DetailData

Раз "религия своя", то и универсальная реализация должна быть адаптивной, а не заточенной под чью-то.

Пожалуй, я бы приветствовал такую концепцию как "локатор внешних значений", что ли. То есть, если имеется неинициализированный параметр/макрос, запрос обращается к локатору с вопросом, не найдется ли одноименного значения. Ну а разработчик имеет возможность добавлять собственный код поиска - например, Вы могли бы парсить тот самый formname.datasetname. Ну а у меня во фреймворке есть одно место, где такой локатор был бы весьма уместен.

grexhide
2. Глобальный поиск, в том числе по формам (GExperts) - это дело плевое, на самом деле.

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

grexhide
3. Тем не менее, идея эта - не нова, и даже вовсе не идея - лишь попытка получить примерно тоже самое, что мы имеем (кхм, возможность наблюдать) в случае Oracle Forms

Хм. А стоит ли повторять все те глупости, что мы имеем, только потому, что где-то мы их имеем?
20 май 07, 01:17    [4160012]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54542
Блог
grexhide
Во первых нет (второй случай)

Второй случай, согласен, "внутримодульный". Подумав - я не вижу особой нужды в нем, но и особых причин возражать тоже не вижу, претензии на уровне "не нравится". Первый случай - жестко не согласен.

grexhide
Я нахожу весьма удобным примерно следующее:

DBComboBox.LookupSQL := 'SELECT * FROM C_CONTRACTS WHERE CLIENT_ID = :CLIENT_ID'

Нисколько не возражаю, но обсуждаемая фича для этого не нужна. Для этого нужно устроить между DBComboBox.DataSource.DataSet и DBComboBox.LookupDataSet самый что ни на есть обычный master-detail, без всяких фокусов. Одна строчка кода в DBComboBox.

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

Может быть. Тем не менее, практическое применение именно в такой формулировке - согласен, несколько экономит время, но пожалуй относится к тем случаям, когда лично я не ленился бы написать несколько строк кода. Как пример ситуации, о которой я думаю - скажем, разноска платежей. Слева платежи, справа счета, и кнопка "Сопоставить", делающая единственный Query.Execute. Ну и Query, активно сосущий параметры слева и справа.
20 май 07, 01:27    [4160013]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
softwarer

grexhide
Впрочем, идею глобальных макросов я бы не назвал сильно удачной (в случае именно констант):

Автогенератор - хуже, имхо. Как и любая денормализация, это то, за чем нужно специально следить. Выполнив запрос сразу после соединения, я получаю гарантированно актуальный результат; в Вашем варианте мне приходится верить в то, что Вася не забыл запустить генератор после того, как поправил перепутанные им значения констант А и Б.

Т.е. Вы предлагаете константы вести на клиенте отдельно, на сервере отдельно? Да нет уж, пусть лучше Вася запускает генератор, и пакетов и .pas/.dfm файлов, а сами константы ведёт в отдельных таблицах, чем (боже упаси) в свойствах компонента TSession.


softwarer
grexhide
С таким же успехом константы-макросы можно вызывать напрямую

Можно. Но неудобно.

Исторически первое, для чего я реализовал этот механизм - это для подстановки значения в запросы вида

select
...
from &Schema.T1 T1, &Schema.T2 T2, ....

Далее это оказалось удобно и для констант (через макросы, а не через параметры - потому что в запросах как правило используется именно одно конкретное значение).

А чем не устроил ALTER SESSION SET CURRENT_SCHEMA ? (плюс механизм приватных синонимов?)
Не слишком ли большая цена?


softwarer
grexhide
Т.е. глобальные макросы... И вовсе не нужны (и даже вредны - т.к. они глобальные, пусть и в пределах сессии, т.к. есть еще и вложенности, и пользовательские фильтры и масса других, потенциально конфликтных мест).

Прошу прощения, если не понял всей глубины мысли, но для меня это выглядит бессмысленным набором слов. Я не увидел ни одного аргумента, такое впечатление, что просто реакция на самопридуманное Вами слово "глобальный" (причем от человека, который, по всей видимости, пользуется глобальными переменными Application, Screen итп, и вряд ли сильно страдает от этого).


&Schema - а есть уверенность, что кому то (к примеру - пользователю, ваяющему запрос на custom-отчет) не захочется наполнить этот макрос какой то своей отдельной смысловой нагрузкой?

Кроме того, сами же и признались, что в случае вложенности макросов - грабли обеспечены практически сразу (не говоря уже про бесконечный цикл MacroByName('schema').Value := '...... &schema.....')

softwarer

grexhide

1. Ну... тут у каждого религия строго своя. К примеру - я использую только следующие имена дейтасетов:

Q
Data
MasterData
DetailData

Раз "религия своя", то и универсальная реализация должна быть адаптивной, а не заточенной под чью-то.

Ну да..

softwarer

Пожалуй, я бы приветствовал такую концепцию как "локатор внешних значений", что ли. То есть, если имеется неинициализированный параметр/макрос, запрос обращается к локатору с вопросом, не найдется ли одноименного значения. Ну а разработчик имеет возможность добавлять собственный код поиска - например, Вы могли бы парсить тот самый formname.datasetname. Ну а у меня во фреймворке есть одно место, где такой локатор был бы весьма уместен.

Хоть и опять "глобализация", но... в принципе да, именно так. Впрочем, никто не мешает этот локатор выносить и на уровень сессии, и на уровень дейтасета (в приоритетах).

softwarer

grexhide
3. Тем не менее, идея эта - не нова, и даже вовсе не идея - лишь попытка получить примерно тоже самое, что мы имеем (кхм, возможность наблюдать) в случае Oracle Forms

Хм. А стоит ли повторять все те глупости, что мы имеем, только потому, что где-то мы их имеем?

В формсах много глупостей, но это - несколько не тот случай. Тем более, его вполне можно сделать и более гибким (нигде не говорилось ведь, что form_name - это какая то абсолюная вешь (в себе). Её вполне можно сделать и относительной - пусть и через тот же локатор (кстати, действительно, в случае приоритета оного вопрос решается лучшим образом)).


P.S. Мда... перечитав оное.... начинаешь понимать, почему AnyDAC - настолько не популярен у начинающих (в своём слегка шокирующем наборе опций). И документации нет, и суть/назначение/первопричина - как то ну очень туманна и не всегда очевидна.

Лучше уж штудировать... ADO.NET. Простой и деревянный, прям как двери. Благо и толмудов, разжёвывающих банальности этого поделия - вагон, примеров тележка, да и MSDN толстым слоем...
20 май 07, 01:37    [4160019]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
softwarer

grexhide
Я нахожу весьма удобным примерно следующее:

DBComboBox.LookupSQL := 'SELECT * FROM C_CONTRACTS WHERE CLIENT_ID = :CLIENT_ID'

Нисколько не возражаю, но обсуждаемая фича для этого не нужна. Для этого нужно устроить между DBComboBox.DataSource.DataSet и DBComboBox.LookupDataSet самый что ни на есть обычный master-detail, без всяких фокусов. Одна строчка кода в DBComboBox.

Да не нужно там никаких строчек.
Только декларация в .DFM, и не более того. Master-Detail в данном случае - как раз неявный (и вовсе не между дейтасетами, а между TDataSet и каким примитивом TOraQuery, с unidirect поведением оного).

Тем не менее, это довольно показательный пример необходимости связывания SQL запросов в параметризации, без применения какой либо дополнительной строки кода (впрочем, для компонента можно хоть и двести написать, но речь сейчас не столько о компоненте, сколько о подходе)

softwarer

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

Может быть. Тем не менее, практическое применение именно в такой формулировке - согласен, несколько экономит время, но пожалуй относится к тем случаям, когда лично я не ленился бы написать несколько строк кода. Как пример ситуации, о которой я думаю - скажем, разноска платежей. Слева платежи, справа счета, и кнопка "Сопоставить", делающая единственный Query.Execute. Ну и Query, активно сосущий параметры слева и справа.


Вот видите. Но моя религия - не писать банального и тривиального кода. Тем более, зависимость описана в самом тексте SQL запроса, зачем нужно еще какие то подпорки master-detail городить?

Опять же, нагородили в одном месте, а вот теперь - нужно скопировать контрол выбора договоров в другое место (или изменить его тип решили, с ComboBox на LOV). В моем случае - просто сработали на уровне декларации (copy/paste). В вашем же случае - и copy/paste декларации, и copy/paste тривиального кода, который, в силу своей тривиальности - имеет все шансы быть "недосмотренным", тем более - на свойствах (events), которые в Delphi10/11 иногда, блин, не копируются (по вполне понятным причинам).
20 май 07, 01:45    [4160022]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
Sleepy_PIP
Member

Откуда:
Сообщений: 415
а Net-8 с русскими логинами - не получится?
Что было ОЧЕНЬ не плохо.
При переходах между 9.2.0.4 и 9.2.0.8 (и даже 9.2.0.7) - оракл сменил типизацию (козлы).
причем может быть даже ранее. нет, все приведенные ораклом и тут рецепты не помогают ибо сменена типизация заданного явно Number(10,0) с флоата ( в 9.2.0.4) на Integer в (9.2.0.8 или рнее) (интресно особенно для программеров - как теперь представлять number10 если к примеру в ОДАК-е он уже не представляется как 64-х битное!!). Причем замечу в пику критикам - в доках к патчам отб этом ни гу гу - только о не явном задании нумбер есть. типа number(10) - и ВСЕЕЕЕ! если будете наезжать - пож. конкретные ссылки. ибо прошерстил что мог.
Изменеия четко отразились на приложениях ОДАК и БДЕ ...
Я считаю первое и самое главное - это править оракловых индусов. ибо если такое произойдет к примеру в банке при не грамотром и с не полным тестом переходе ВНТРИ одной версии - банк просто ляжет ... то что ораклу плеввать на своих клиентов - ну тут судить рядить можно сколько угодно. но факты на лице ....
Что еще хочется - все что а ОДАК но под c# ...
Что еще хочется - собственных виз. компонент типа хотя-бы сложных таблиц, ориентированных именно на оркал ...
Что еще хочется - компоненты для объектного маппинга. пока это модно (хотя хибернет эффективен только при малых проектах. но внутри больших - могут быть и локальные решения конечно - а они удобны).
Чсаз уже устал. но тема интересует. наборосаю еще план ...
20 май 07, 03:47    [4160067]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54542
Блог
grexhide
Т.е. Вы предлагаете константы вести на клиенте отдельно, на сервере отдельно?

Саш, когда проснетесь, начните сначала. Я понимаю, что Вы писали это в полвторого ночи, но тем не менее...

grexhide
А чем не устроил ALTER SESSION SET CURRENT_SCHEMA ?

Думаю, Вы и сами легко можете назвать ситуацию, в которой он мало что дает.

grexhide
(плюс механизм приватных синонимов?)

Фи, какая дрянь.

Это уже действительно вопрос религии. Похоже, Вам очень нравится идея плодить "денормализацию в метаданных". Мне же она очень не нравится.

grexhide
&Schema - а есть уверенность, что кому то (к примеру - пользователю, ваяющему запрос на custom-отчет) не захочется наполнить этот макрос какой то своей отдельной смысловой нагрузкой?

При желании от этого легко защититься, например, предложенным Вами образом (квалификатором). Мне это не требовалось, но в принципе согласен с такой постановкой вопроса.

grexhide
Кроме того, сами же и признались, что в случае вложенности макросов - грабли обеспечены практически сразу (не говоря уже про бесконечный цикл MacroByName('schema').Value := '...... &schema.....')

[Эмоциональная характеристика skipped]. Во-первых, я ни в чем не "признавался", во-вторых, сказанное не является аргументом против "глобальных" макросов, поскольку в случае "локальных" ведет себя точно так же.
20 май 07, 08:03    [4160097]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
PPA
Member

Откуда: Караганда -> Липецк
Сообщений: 798
softwarer

grexhide
А чем не устроил ALTER SESSION SET CURRENT_SCHEMA ?

Думаю, Вы и сами легко можете назвать ситуацию, в которой он мало что дает.


Подскажи эту ситуацию?
20 май 07, 08:31    [4160106]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54542
Блог
PPA
Подскажи эту ситуацию?

Приложение, распределенное по нескольким схемам.
20 май 07, 08:52    [4160107]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
Sleepy_PIP
а Net-8 с русскими логинами - не получится?
Что было ОЧЕНЬ не плохо.
При переходах между 9.2.0.4 и 9.2.0.8 (и даже 9.2.0.7) - оракл сменил типизацию (козлы).

Да, там была очень веселая схема.

В 9.2.0.5 они стали понимать number(10) union number(10) как... number(10), а не как number,
(кстати, в 10g R2 так изначально, не уверен насчет R1), потом ... в 9.2.0.6 не нашли ничего более умного, чем поменять обратно, т.е. number(10) union number(10) стал опять ... number. Дальнейший ход событий я уже потерял.

Но эту проблему не решить на уровне DAC, это чистый внутренний баг Oracle. Как вариант - я обходился механизмом обзоров, с применением CAST AS ..... USER_PACKAGE.SUB_TYPE.


Sleepy_PIP

причем может быть даже ранее. нет, все приведенные ораклом и тут рецепты не помогают ибо сменена типизация заданного явно Number(10,0) с флоата ( в 9.2.0.4) на Integer в (9.2.0.8 или рнее) (интресно особенно для программеров - как теперь представлять number10 если к примеру в ОДАК-е он уже не представляется как 64-х битное!!). Причем замечу в пику критикам - в доках к патчам отб этом ни гу гу - только о не явном задании нумбер есть. типа number(10) - и ВСЕЕЕЕ! если будете наезжать - пож. конкретные ссылки. ибо прошерстил что мог.
Изменеия четко отразились на приложениях ОДАК и БДЕ ...
Я считаю первое и самое главное - это править оракловых индусов. ибо если такое произойдет к примеру в банке при не грамотром и с не полным тестом переходе ВНТРИ одной версии - банк просто ляжет ... то что ораклу плеввать на своих клиентов - ну тут судить рядить можно сколько угодно. но факты на лице ....

Сколько эмоций ;))) Я бы не назвал, если честно, практику TFloatField - хорошо подходящую к типу NUMBER (не NUMBER(10)). Тут как раз более уместным был бы какой TCurrencyField или TOraField (BCD). Вот как раз этот вопрос в AnyDAC решён (можно задавать маппинги типов).

Sleepy_PIP

Что еще хочется - все что а ОДАК но под c# ...

Не дождетесь ;))) И вообще, Delphi.NET это уже покойник, и я был бы очень рад, если бы он им остался навсегда.

Sleepy_PIP

Что еще хочется - собственных виз. компонент типа хотя-бы сложных таблиц, ориентированных именно на оркал ...

Интересно, чем это определяется "сложность" таблиц?

Sleepy_PIP

Что еще хочется - компоненты для объектного маппинга. пока это модно (хотя хибернет эффективен только при малых проектах. но внутри больших - могут быть и локальные решения конечно - а они удобны).
Чсаз уже устал. но тема интересует. наборосаю еще план ...


Вот тут поддерживаю. Мы уже говорили про автогенерируемые типизированные коллекции строк, с отражением схемы Master-Detail взаимосвязей дейстасетов в оно генерируемые коллекции. В разделе Delphi

А вот насчет уже PHibernate - это уж увольте. Не стоит тянуть в рот всякую дрянь, которая пусть и очень популярна в некоторых (так и подмывает подвернуть масонских ;) кругах.
20 май 07, 08:53    [4160108]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
softwarer
PPA
Подскажи эту ситуацию?

Приложение, распределенное по нескольким схемам.


Редкостная дрянь. Так а что там было не так с приватными синонимами?
Ну или с механизмами обзоров (VIEW?)

Лично я в таких случаях стараюсь поступать как раз известной методикой - клиента не должны волновать физические аспекты модели данных, и вместо

CLIENTS.CLIENTS$
CLIENTS.CONTRACTS$

INVOICE.DOCUMENTS$
INVOICE.DOCUMENT_ITEMS$

BILLING.DOCUMENTS$
BILLING.DOCUMENT_ITEMS$

Я бы предпочел (соотвественно) обзоры (собственно очередной ROT, очень помогающий при рефакторинге бд и правкой косяков вроде UNION ALL и пр.), т.е. клиенту видны строго в текущей схеме:

С_CLI
C_CTR

INV_DOC
INV_ITEM

BILL_DOC
BILL_ITEM


Дёшево и сердито (переключаться между схемами, к примеру разных отделений, можно одной командой ALTER SESSION), кроме того - обзоры могут быть не менее эффективно обновляемы (если не хочется городить огород из хранимых процедур и instead of триггеров DML).

P.S. Что то вы намудрили, как ни крути, с физической привязкой клиента к схеме (пусть и за счёт substitution variable).
20 май 07, 09:02    [4160111]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8561
softwarer
grexhide
Т.е. Вы предлагаете константы вести на клиенте отдельно, на сервере отдельно?

Саш, когда проснетесь, начните сначала. Я понимаю, что Вы писали это в полвторого ночи, но тем не менее...


А... я понял глубину мысли (проснувшись).

Т.е. вы при запуске приложения - автоматически заполняете эти grobal macro от констант пакетов?

Мда.... Ну даже не знаю, все равно как то... однобоко..

А как быть в данном случае:

procecude TForm.Button1Click(Sender: TObject); // утрируем ;
begin
  PACKAGE_NAME.PROCEDURE_NAME(PCONST.CONSTANT_1, PCONST.CONSTANT_2, 'lalala', DataSummary.Value);
end;

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

P.S. Т.е. идея глобальных макросов.. Как то сомнительна получается. Вроде и нужна, но больше вреда просматривается, чем пользы ;) sсhema - это же частный случай, и более уместным тут был бы (IMHO) примерно следующий подход:

SELECT * FROM <SCHEMA>.TABLE_NAME 

на клиенте (<SCHEMA> заменяется перед стадией prepare). Ну и каким то образом реализованный IDE Wizard, подволяющий уже препарированные запросы (к примеру - за счет тегов комментариев) "носить" туда/обратно в PL/SQL Developer (который сам не понимает <SCHEMA>, естественно).
20 май 07, 09:12    [4160118]     Ответить | Цитировать Сообщить модератору
 Re: Delphi'цы: Что вам необходимо, что бы перейти на AnyDAC ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54542
Блог
grexhide
Редкостная дрянь.

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

grexhide
Так а что там было не так с приватными синонимами?

Cкорее я бы задал вопрос, что с ними "так".

grexhide
Лично я в таких случаях стараюсь поступать как раз известной методикой - клиента не должны волновать физические аспекты модели данных, и вместо

CLIENTS.CLIENTS$
CLIENTS.CONTRACTS$

клиенту видны строго в текущей схеме:

С_CLI
C_CTR

Что ж, замечательный и наглядный пример, давайте думать.

Итак, прежде всего, Вы предлагаете делать объекты известными под двумя разными именами. Программируя модуль CLIENTS, я работаю с таблицей CLIENTS$, в других местах.... Соответственно нетрудно проутрировать сценарий типа "Мыкола, слыхав як кляти москали C_CLI кличуть? .... Повбывав бы". По сравнению с этим программист, делающий форму FormCosts для работы с таблицей PRICES, поступает нормально и разумно.

Далее, если чуть подумать, оказывается, что программисту клиента практически все равно, писать ли

from
  XXX.CLIENTS

или

from
  XXX_CLIENTS

Никакой особой "привязки к физической модели" тут нет, вопрос голого синтаксиса. Если символ подчеркивания используется и внутри имен таблиц, второй способ слегка ухудшает читаемость, в остальном разницы нет. То и другое - ссылка на логическую модель; программист знает, что он ссылается на модуль XXX и явно указывает этот факт. И это правильно - надеюсь, Вы не будете возражать против утверждения, что программист должен понимать логику того, что он делает?

Технологически же первый вариант удобнее, в частности, удобнее тем, что ничем не отличается от синтаксиса

from
  &XXX.CLIENTS

При этом мы получаем вполне удобную и максимально надежную методику работы с многосхемными БД, без всякого рода костылей, за целостностью и адекватностью которых надо отдельно следить (я, в частности, до сих пор вспоминаю огромное удовольствие работы в ситуации, когда люди наплодили две схемы, изначально одинаковых, а потом разошедшихся, и синонимы, беспорядочно ссылавшиеся на объекты то той, то другой). В качестве побочного бонуса имеем метаинформацию - какой запрос от каких модулей зависит (а следовательно - возможность предсказать, что будет, если мы инсталлируем только некоторые модули).

grexhide
Дёшево и сердито

Согласен. Вот только я всегда считал это аргументом "скорее против" какого-то решения.
20 май 07, 09:32    [4160121]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 52   вперед  Ctrl
Все форумы / Delphi Ответить