| |
|
|
| | Доброго времени суток!
подскажите пожалуйста, как побороть следующую проблему:
есть отчет, основанный на запросе1, в нем подч.отчет, основанный на запросе2
(каждой записи из зпр1 может соответствовать несколько записей из зпр2)
раньше я нумеровал (через свойства поля, с автосуммой) строки для осн.отчета отдельно, для подч.отчета отдельно, получалось что-то вроде того:
1 объект А
2 объект Б
3 объект В
1 подч.объект А
2 подч.объект Б
4 объект Г
и т.д. вроде все было хорошо до поры, до времени.
ТЕПЕРЬ шефу надо СПЛОШНУЮ НУМЕРАЦИЮ по всему отчету, т.е должно получиться примерно так:
1 объект А
2 объект Б
3 объект В
4 подч.объект А
5 подч.объект Б
6 объект Г
я думал - все просто, ща збацую - как бы не так: через свойства полей (для нумерации) нет возможности, пробую кодить, вроде что-то получается, но только для осн.отчета, для подч. отчета нет - хоть убейся ап стену!
ПОМОГИТЕ! | |
| |
| |
| |
 14 Кб. |
|
| | А так ежели попробовать => | |
| |
| |
| |
|
|
| | Child во множественном числе будет Children
(но не Childs) | |
| |
| |
| |
|
|
| | Спасибо. 
Я почти в курсе.
Зачастую несколько вольно пользую "сокращения".
:) | |
| |
| |
| |
|
|
| | Спасибо, почти заработало!
почему почти...
1) с какого то перепугу на каждой новой странице пропускается 1 номер (в самом начале), можетэтому виной верхний колонтитул?
2) таже самая ситуация со строками в подчиненном отчете - следующий номер идет на 2 больше, чем предыдущий (из предыдущей строки осн. отчета), а вот следующий номер из подч.отчета в осн. отчет бъет четко.
чет хрень какаято | |
| |
| |
| |
14 Кб. |
|
| | Понятно, чуда не свершилось. :)
А так => | |
| |
| |
| |
|
|
| | '''report rpt_parent
Private Sub ЗаголовокОтчета_Format(Cancel As Integer, FormatCount As Integer)
Call ResetCounter
End Sub | |
| |
| |
|
|
| |
|
|
| | Спасибо за помощь!
В этот раз намного лучше, я уж думал пора это ...
однако - вот такие непонятки => http://zalil.ru/30750896
я уж в VBA и пошагово и с заходом, и ... все впустую | |
| |
| |
| |
|
|
| | ХР рулит - 2007 не у всех есть, вернее мало у кого  | |
| |
| |
| |
|
|
| | Попробуйте все-же
'''report rpt_parent
Private Sub ЗаголовокОтчета_Format(Cancel As Integer, FormatCount As Integer)
Call ResetCounter
End Sub
|
| |
| |
| |
| |
|
|
| | Зачем? (второй раз)
Вызов ResetCounter в моем примере имеется на Open отчета. | |
| |
| |
| |
|
|
| | на опен отчета вызывать функцию не НАДО | |
| |
| |
| |
|
|
| | to обоим
а вы ему не пробовали посоветовать поменять структуру | |
| |
| |
| |
|
|
| | может такая структура задана внешними факторами
-ексель-таблица
-рукописная бумажка
.........
через год встанет проблема резмещения столбиков по ширине листа
-или понадобится разместить в столбик по каждому году план,факт,отклонение,процент(с строчку явно не влезет)
-или выдать отчет за 2009-2010 год
-или пустографку на 2012-2013
так из одного отчета делается 5-10-33(реальность ...янв, с н.г,фев,с н.г,за 1 кв,....за 1 пол,...за год) | |
| |
| |
| |
|
|
| |
может такая структура задана внешними факторами
|
прога работать будет только до 2015-го дальше все переписывать КОД или копировать файл, стирать данные и всем объяснять что 2011 это 2016-й | |
| |
| |
| |
|
|
| | почему только до 2015 года?
добавляешь новые поля в нужные таблице, редактируешь слегонца теже поля в запросе и все хоть до второго пришествия
кто-то скажет гемор, может быть, но делать версию отчетов по образу и подобию календаря Майя не хочется, зачем я тогда нужен буду шефу | |
| |
| |
| |
|
|
| |
но делать версию отчетов по образу и подобию календаря Майя не хочется
|
это как  | |
| |
| |
| |
|
|
| | это я имею ввиду сбацать отчеты, таблицы и проч. сразу лет так на 10 вперед, с кварталами , месяцами и проч.
не придирайтесь пож. к словам.
просто очень нужно решение проблемы - или на уровне VBA, или переводом это опять же через прогу в отфарматированном виде в Ворд, или еще как нибудь - но решение. | |
| |
| |
| |
|
|
| | перевести таблу на
ид,показат,год,мес,план\отчет,сумма
1 вал 2010 1 план 123000
2 вал 2010 1 отчет 32000
...................
через перекрестный выбирай что надо
-планы за 2010-2011 по месяцам, кварталам,году
-сравнение по месяцам 2010 и 2011 я10,я11,разн,процент,
-или кварталам
-или годам
-все показатели за 2010
месяц\вал\объем\...........
янв
февр
....
---------------------------------------
отчеты конечно лучше освоить в НТМ с печать в ворде
образец я выкладывала(кажется Коту)
---------------------------------------
в общем случае форма отчета не должна зависеть от периода
какие годы-месяцы выбраны --по тем и отчет с автоподгонкой ширины столбцов
--------------------------------------
для начальства --просмотр в НТМ с возможностью увеличить размер шрифта для слабо-видящих
для печати в ворд --шрифт=9(если при просмотре табла не влезает в лист --уже в ворде заменить на 8 или 7)
для доработки --ексель
-----------------------------------
и все с одного формирование --управление кнопками открытия | |
| |
| |
| |
|
|
| | вот и я о том же,
добавлю - перекрестные отчеты через подключение Excel - и будет счастье.
вот про это
http://www.techdays.ru/videos/1227.html | |
| |
| |
| |
|
|
| | БОЛЬШОЕ СПАСИБО ВСЕМ, извините если успел надоесть с этой назойливой темой
буду изучать HTM, что это за зверь такой ... | |
| |
| |
| |
|
|
| |
на опен отчета вызывать функцию не НАДО
|
Аргументы?
Почему на опен отчета не надо, а на форматирование заголовка надо?
:) | |
| |
| |
| |
|
|
| | на опен происходит открытие данных и прочее( 1 раз)
форматирование и печать (часто по нескольку раз) для заголовка, данных,колонтитулов. поэтому
1-инициализация переменных, выводимых в отчет -в заголовке
2-переменных для выбора -в опен
иногда (особенно пр необходимости не-отрывать заголовок от данных) происходит многократное форматирование
в этом случае надо еще проверять FormatCount
обычно вставляю debug.print для всех опорных переменных во все форматирования и печати
окупится многократно
иногда вывожу трассировку во внешний текстовый файл, если предвижу осложнения | |
| |
| |
| |
|
|
| | Сколько раз будет вызвано форматирование заголовка отчета? | |
| |
| |
| |
|
|
| |
Сколько раз будет вызвано форматирование заголовка отчета?
|
при прямой печати --1 раз
при предварительном просмотре и затем печати --2 раза
при предварительном просмотре, установка параметров страницы и затем печати --3 раза | |
| |
| |
| |
|
|
| | Да.
Причем сброс ни на Open, ни на Format заголовка при 2 и 3 вариантах не спасают от чехарды.
Остается любимое - вывод в xls/html.
:) | |
| |
| |
| |
|
|
| | Прислушался по повдоу Debug.Print
вставил через строчку в прогу присланную Lukas'ом (зы - классная вещь, отдельное спасибо), установил БреакПоунт и пошагал и что-же получается:
при перелистывании на новую страницу счетчик гуляет по одной и тойже записи трижды: 2 раза на предыдущей странице и 1 раз но последующей, однако номер в поле бьет четко. Это как бы слегка напрягает, но фигня, вроде как объяснение в голове вырисовывается.
А вот когда из строки основного отчета переходим на строки подчиненного отчета - вот тут мультики: сперва счетчик проходит по каждой строке, присваивает правильное порядковое значение, А ПОТОМ, ЗАЧЕМ-ТО ЗАНОВО ЭТИ ЖЕ СТРОКИ ПЕРЕСЧИТЫВАЕТ и соответственно присваивает уже новые неправильные значения - вот здесь и всплывает чехарда. ПОЧЕМУ? ЗАЧЕМ?
Вот и вырисовывается некая закономерность - какое количество строк подчиненного отчета соответствует строке из основного отчета - ровно настолько х на 2 будет приращение последнего (правильного) порядкового номера, т.е. если 2 строки, то плюс 4 пункта. о как ... | |
| |
| |
| |
|
|
| | Все та-же проблема остается, даже если в ЗаголовокОтчета_формат прописать сброс счетчика.
меня терзают смутные сомнения по поводу, что глюк с нумерацией в подч.отчете всплывает из-за сложности запросов.
Поясню (напомню): отчет и подч.отчет построены каждый на своих запросах (по сути они одинаковые, только таблицы разные).
Каждый запрос "тащит" данные из двух таблиц - одна основная (где запись (строка) принадлежит только уникальному значению, а вот из второй таблицы значений (строк) может быть несколько.
И вот подозрения у меня падают как раз таки на значения из подчиненных таблиц, т.е когда я их определенным образом отбираю, некоторые записи, естественно, не "тащутся", однако они ведь "ПРИВЯЗАНЫ" к основной записи. Вот и получается (м.б.) что в отчете они не отображаются, а где то в ядре считаются. | |
| |
| |
| |
|
|
| | to всем участвующим
никаких экселей, ни каких бумажек, база набиралась ручками. 5 с лишним лет жил-не тужил, добавлял новые данные и все, пока шефу не понадобилась вдруг сквозная нумерация.
по поводу - "а вы ему не пробовали посоветовать поменять структуру" - структура отрабатывалась долго и нудно, в конечном итоге остановились на том что есть.
Хотя - если есть конструктивные предложения - всегда спасибо.
никаких расширений существующего отчета не будет.
если что и понадобится новое - то все будет формироваться на основе все тех же (основных) 4 таблиц
подозреваю всеж, что где-то глюк со связями в таблицах | |
| |
| |
| |
|
|
| | Беда в том, что в обоих отчетах группировка.
Отсюда сбой нумерации. | |
| |
| |
| |
|
|
| | to Lukas
и как же жить без группировки?
кстати, в свое время, здесь же на форуме и посоветовали именно так и собрать отчет.
пы-сы: я попробовал убрать группировку - не получается привязать записи из подчиненного отчета к конкретной записи основного. | |
| |
| |
| |
|
|
| | Группировать можно в запросе-источнике. | |
| |
| |
| |
|
|
| | ну не знаю ... как это в запросе, а потом связать в отчете одно с другим (в отчете ведь для группы по ID
отбираются конкретные записи в подч. отчете также по этому-же самому ID)
Видимо остается только одно - старый испытанный способ - распечатать отчет с пустыми полями для номера по порядку и пронемуровать строки ручками ... все 4000 с лишним, а кому щас легко? | |
| |
| |
| |
|
|
| | все не читал, поэтому возможно повторю кого нибудь
а если в отчет вставить поле где написать =Function_NPP , в которой будем брать глобальную переменную и увеличиваем ее на 1 (при открытии отчета присваиваем ей 0).
может не совсем кошерно - но хоть както | |
| |
| |
|
|
| |
|
|
| | а почему собственно | |
| |
| |
