Group By в Аттейне

[Yoil]

Господа, подскажите, а если в Аттейне какая-нибудь фича, которая действует подобно SQL'вскому Group By?

COUNT(COUNTAPPROX) есть, SUM есть(в Аттейне - CALCSUMS), а вот есть ли что-нибудь, что интерпретируется в SQL как запрос с использованием Group By?

В отчетах по идее есть такая штука, как GroupTotalFields, но как-то оно вроде не так работает...

[finn]

в отчетах есть что-то подобное
только надо заполнить
три поля:
в свойствах Data Item (к примеру G/L Entry)
GroupTotalFields например Document No.
TotalFields например Amount
и убедиться что в свойстве
DataItemTableView стоит ключ сортировки включающий Document No.
например Document No.,Posting Date
и в печатной форме надо вставить section типа GroupFooter
и размеcтить на нем Document No. и Amount

а вообще у аттайн есть вариант поставки под MS SQL
и вся мощь обычного SQL в ваших руках
если вдруг надо побыстрому данные вытащить

[Yoil]

насчет использования GroupTotalFields - такую фишку я знаю.
Берем для примера таблицу G/L Entry и считаем в ней Amount, "Credit Amount" и "Debit Amount" по каждому "G/L Account No.". (все делается вышеуказанным способом). Дык вот время выполнения в Аттейне(причем брал операции только за 2003 год) - почти три минуты(166 секунд).
А теперь пишем подобную муть в Query Analyzer
select sum(Amount), sum([Debit Amount]), sum([Credit Amount])
from [G/L Entry]
where ([Posting Date] between '1/1/2002' and '12/31/2003') group by [G/L Account No.]

Выполняется за секунду.

То, что есть в Аттейне - это не инструмент SQL, это просто избавляет кодера от пары-тройки лишних строк кода и ничего более. А изначально интересовало, можно ли использовать именно Group By SQL, т.е. мощный и быстрый аппарат.

Еще вопрос:

Цитата:

а вообще у аттайн есть вариант поставки под MS SQL и вся мощь обычного SQL в ваших руках

- не могли бы Вы, уважаемый finn, пояснить, что имеется в виду? Если то, что в Аттейне можно работать с базой, расположенной на SQL-сервер - дык это понятно, вот только полной функциональности SQL-сервера все равно нет, что очень обидно...

[finn]

подскажите сколько записей в G/L Entry ?
3 минуты слишком много как мне представляется.
в свое время наблюдал значительное увеличение производительности
после простановки на клиента свежих
драйверов Microsoft Data Access (ставил версию 2.7)

но все равно в любом случае будет медленне чем sql запрос.

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

а про запрос напрямую к базе я имел в виду что вы и поняли
есть база sql значит можно писать к ней запросы
(у некоторых ведь родной формат navision используется)

[Yoil]

Записей в G/L Entry - шестой порядок.
Не суть важно, главное - что это все-таки не сиквельный Group By
Насчет Microsoft Data Access - попробую, как время будет, спасибо за совет.

[Grizzly]

Цитата:

Изначально опубликовано finn
подскажите сколько записей в G/L Entry ?
3 минуты слишком много как мне представляется.

К сожалению, может быть значительно дольше :-(

Дело в том, что Attain и SQL Server используют принципиально разные модели данных. SQL Server ориентирован на работу со множествами (как, собственно, и все реляционные СУБД), а Attain - на работу с записями. Из этого следует два вывода:

1. Attain не может использовать реляционный аппарат (в том числе и агрегатные функции), так как сам он "мыслит" на более низком уровне. Сооответственно, он не может использовать все возможности и реляционных СУБД.

2. Операции по обработке данных производятся на клиенте (Свойство GroupTotalFields используется только лишь для того, чтобы определить поля, которые надо контроллировать и при изменении их значения вызывать соответсвующие триггеры), поэтому все данные, которые необходимы для обработки, сначала извлекаются сервером, передаются по сети на клиент и затем обрабатываются. Что конечно же дольше, чем если бы эта операция была выполнена на сервере, а возвращен был только результат.

Что касается "рецепта" для решения подобных проблем, то я абсолютно согласен с Finn. Существует всего два средства:
1. Использование в Attain технологии SIFT
2. Использование внешних средств генерации отчетности, которые, кстати, можно легко интегрировать в среду Attain

[Rungart]

2 Grizzly :
Если можно, то пожалуйста, напишите подробнее о внешних средствах генерации отчетности, это было бы очень интересно.

[Yoil]

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

[Grizzly]

Генераторы отчетов - это класс программных продуктов, предназначенных для использования самостоятельно или с совместно другими программными системами. На рынке их сейчас много. Есть российские и зарубежные разработки. Отличаются по функциям и по цене. Рассчитаны на то, что их могут использовать как опытные, так и начинающие пользователи. Наиболее известными являются CrystalReport и ReportSmith. Первый используется как часть очень многих коммерческих программных продуктов, в том числе и систем управления предприятием (scala, exact).

В их основе лежит та же идея, что и в дизайнере отчетов в Attain. Пользователь определяет внешнее представление отчета и схему данных. В качестве источника данных могут выступать практически любые реляционные БД, dbf и txt, все к чему может быть организован доступ через ODBC, BDE и т.д.. Схема данных формируется с использованием:
- выражений SQL
- специальных экспертов (в итоге все равно генерируются SQL выражения)
- в некоторых генераторах отчетов, если средств SQL недостаточно, для рассчета полей и управления выводом могут быть использованы также другие языки программирования (VBasic)

Внешнее представление отчета создается практически также как и в Attain, с помощью визуальных средств.

Отчеты (их описания) сохраняются обычно ввиде файлов, некоторые - в БД.

Так как генераторы отчетов предназначены для использования совместно с другими программами, то имеют очень развитые средства интеграции (интерфейсы), в том числе OLE, DDE, COM и т.д. И уж конечно все могут выполнить отчет из командной строки.

Выполненный отчет может быть распечатан или сохранен в различных форматах.

[Rungart]

Большое Спасибо.

[Yoil]

Слышал я страшные вещи, что из-за корявых названий, которые дает Аттейн таблицам, тот же CrystalReport отказывается, в отличие от Query Analyzer, например, с ними работать... Сам не проверял, нет сейчас софта под рукой - кто-нибудь может подтвердить/опровергнуть? Вообще интересно, кто какие внешние генераторы реально с Аттейном использовал?

[finn]

есть еще в аттайн у таблиц свойство LinkedObject
по идее если создать просмотр в SQL скажем с group by
и обозвать его по уставу firma$view +
еще какие-то ограничения точно не помню
потом этот просмотр
может быть прилинкован к таблице аттайн с таким же именем
и LinkedObject=Yes
и по таблице уже гнать отчеты
правда сам с SQL просмотром не пробовал
линковался только к excel файлу

[Grizzly]

Цитата:

Изначально опубликовано Yoil
Слышал я страшные вещи, что из-за корявых названий, которые дает Аттейн таблицам, тот же CrystalReport отказывается, в отличие от Query Analyzer, например, с ними работать.

Это и правда и нет.

Когда Crystal Reports обращается к SQL Server напрямую, то да, он отказывается работать с таблицами, чье именование не соответсвует SQL-стандарту. И дело не в "корявых" названиях, а в том, что имена таблиц содержат пробелы. Если обращаться к таблицам, в именах которых нет пробелов, то все работает новрмально.

Если же к SQL Server обращаться через ODBC, то вообще никаких проблем не возникает.