| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как проставить №п/п? [D7, XP]
deras © (2008-07-14 19:36:00)Есть FB2.0
Таблица Т1 имеет поля ID, Date, Num. Заполнены только поля ID и Date. Есть около 3 тыс. записей.
Как проставить в поле Num номер п/п записей, отсортированых по дате?
Спасибо
MsGuns (2008-07-15 20:03:00) [1]>Тын-Дын © (15.07.08 17:36) [28]
>Почему-то все решили, что это накладная, а № - номер строки в ней.
>В топике было про связку по номеру. Т.е. это именно порядковый номер >отчета.
Из фразы топика
Как проставить в поле Num номер п/п записей, отсортированых по дате?
рождается "именно порядковый номер отчета"?
Тын-Дын (2008-07-15 19:32:00) [2]
> Anatoly Podgoretsky © (15.07.08 19:30) [29]
> deras (14.07.08 19:54) [2]
>а остальные отчеты
> будут детализировать первый ( со ссылкой на первый отчет именно по полю №п/п)
Anatoly Podgoretsky (2008-07-15 19:30:00) [3]Ни о каком номере отчета не идет речь, а именно о номерах записей
> Num номер п/п записей,
Тын-Дын (2008-07-15 17:36:00) [4]Почему-то все решили, что это накладная, а № - номер строки в ней.
В топике было про связку по номеру. Т.е. это именно порядковый номер отчета.
MsGuns (2008-07-15 16:50:00) [5]> [24] MsGuns © (15.07.08 16:13)
>Номер позиции в накладной.
И нафиг не нужен. Если накладная отпускная, то она формируется на ПК и только после этого печатается КАК ЕСТЬ. Как правило, сортированная по наименованию товара (товарной группы). И в дальнейшем порядок НЕ МЕНЯЕТСЯ.
Если накладная приходная, то таки да, введенные записи располагаются не в том порядке, как в бумаге. Но это не является нарушением ! Ни один налоговик не придерется к такой чепухе. Главному же вообще по барабану.
Хотя, согласен, бывают случаи, когда требуется располагать записи в порядке их ввода - для этого строки документа сортируются по идентификатору. Хранить же в таблице номер пп есть дурь полнейшая - потому что приводит рано или поздно к геморрою.
Anatoly Podgoretsky (2008-07-15 16:36:00) [6]> Sergey13 (15.07.2008 16:21:25) [25]
Накладные формируются по строгому закону и повторямость 100 процентная, кроме случая повреждения данных.
Sergey13 (2008-07-15 16:21:00) [7]> [24] MsGuns © (15.07.08 16:13)
> Номер пп, очевидно, не является ни характеристикой объекта,
> ни тем более РЕАЛЬНОЙ характеристикой.
Номер позиции в накладной.
ЗЫ: это не наезд (в остальном я с тобой полностью согласен), просто бывают разные случаи. ИМХО.
MsGuns (2008-07-15 16:13:00) [8]В таблицах БД должны храниться реальные объекты с реальными же свойствами. Номер пп, очевидно, не является ни характеристикой объекта, ни тем более РЕАЛЬНОЙ характеристикой.
Он используется лишь для удобства работы с таблицами или отчетами (в конечном счете являющимися "твердой копией" таблиц) и формируется, как здесь было совершенно справедливо отмечено, "на лету", т.е. при формировании КОНКРЕТНОГО списка, отображаемого (печатаемого) в виде таблицы. Очевидно, что номер пп для каждой записи ОДНОГО И ТОГО ЖЕ списка может быть разным, например, при разных сортировках.
Для отображения номера пп в таблице (гриде) достаточно следующее:
В самую левую колонку грида положить поле датасета, не предназначенное для отображения - чаще всего для этого идеально подходит поле идентификатора, если же его нет, то в запрос надо добавить любое поле, например просто как константу (Select '1' as NPP, * FROM TABLE), которое и "уляжется" в самую первую колонку сетки.
В обработчике OnGetText этого поля написать
Text := IntToStr(RecNo);
После этого как бы не был пересортирован на клиента датасет, в самой левой колонке сетки будет "правильная" нумерация строк-записей. (Исключение составляет эффект "дырок", появляющийся в следствие фильтрации - в этом случае следует вместо фильтра самого датасета использовать дополнительные условия выборки в запросе) - т.е. "фильтацию" заменить новой выборкой
Для того, чтобы поместить номер в отчет можно просто положить это поле как колонку отчета либо воспользоваться для нумерации записей средствами самого же компонента репорта
Anatoly Podgoretsky (2008-07-15 12:57:00) [9]> Тын-Дын (15.07.2008 11:59:19) [19]
Но речь то не про номер отчета, а про порядковый номер строчки в отчете. Номер отчета отдельная от отчета вещь, она конечно фиксируется отдельно от отчета, если конечно она есть.
Smile (2008-07-15 12:11:00) [10]
> Тын-Дын © (15.07.08 11:43) [17]
> Твердые копии должна при повторной распечатке должны быть
> идентичными. Гарантии при "формировании на лету" - никакой
/I>
Не считаю это верным подходом (здесь может "спасти" и ксерокс)
Поддерживаю
> Desdechado © (14.07.08 20:43) [6]
> Не нужно хранить то, что может быть сгенерировано налету.
>
Тем более, что это вполне согласуется с
> Smile (14.07.08 19:48) [1]
> Ну, на первый взгляд, в этом нет никакой необходимости.
Desdechado (2008-07-15 12:05:00) [11]
> Номер отчета будет другой, если его на лету генерировать.
> Потому и фиксируется в отдельном поле.
Не путай номер отчета с номером пункта в списке, содержащемся в отчете.
Desdechado (2008-07-15 12:04:00) [12]
> Твердые копии должна при повторной распечатке должны быть
> идентичными.
Такие отчеты сохраняются в сформированном виде в стеке распечатанных отчетов, чтобы их потом можно было повторно распечатать без мурыженья базы.
Тын-Дын (2008-07-15 11:59:00) [13]
> Anatoly Podgoretsky © (15.07.08 11:46) [18]
>
> То есть есть данные в отчете будут совсем другие, тогда
> какая разница на лету номер генерируется или нет.
Номер отчета будет другой, если его на лету генерировать.
Потому и фиксируется в отдельном поле.
Единственное, что это должно быть предусмотрено до, а не после формирования строки все-таки.
Anatoly Podgoretsky (2008-07-15 11:46:00) [14]То есть есть данные в отчете будут совсем другие, тогда какая разница на лету номер генерируется или нет.
Тын-Дын (2008-07-15 11:43:00) [15]
> Desdechado © (14.07.08 20:43) [6]
>
> Не нужно хранить то, что может быть сгенерировано налету.
>
Твердые копии должна при повторной распечатке должны быть идентичными. Гарантии при "формировании на лету" - никакой
Тын-Дын (2008-07-15 11:40:00) [16]Удалено модератором
Johnmen (2008-07-15 11:39:00) [17]Удалено модератором
Тын-Дын (2008-07-15 11:37:00) [18]Удалено модератором
Johnmen (2008-07-15 11:36:00) [19]Удалено модератором
Тын-Дын (2008-07-15 11:29:00) [20]Удалено модератором
Примечание: Обсуждение модерирования
| |
Страницы: 