Драсте...
Всегда так и делал. Только отмечал не актуальные, а "не актуальные". Так для восприятия понятней ИМХО.

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

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

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

Вроде всё что вспомнилось "на вскидку"...

для Хам трамвайный:
:) Спасибо! Такой краткой похвалы (именно так и расцениваю:) я еще не получал. Как и вообще похвалы от тебя в целом :) //от него дождешся... ничего не спрашивает, ничем помочь не дает... хамит постоянно...


для Alexus12:
Alexus12Хорошо, а как быть с такой ситуацией:<...>А как быть с ПОКАЗОМ СТАРЫХ записей? ведь если не попадет в роусорс, на месте этой записи будет пусто...
Ну так почему я и говорил о двух (или более) РЕЖИМАХ работы. Т.е. если у тебя форма в режиме "Только Актуальные", то ну нигде абсолютно оператор не должен умудриться наткнуться на старые данные. В то же время, если оператор знает, что у него есть такой товар (тьфу! опять товар... вообщем, я буду говорить "товар", а ты перефразируй на свой лад), но он "устаревший", или просто хочет что-либо поискать в "устаревших" товарах, то он переводит форму в РЕЖИМ "Включая устаревшие" и уже на этой же самой форме, без какой либо смены интерфейса он может увидеть весь перечень товара. Т.е. в твоем комбобоксе надо менять условия фильтрации. Опять же, если операторы выбирают позиции из комбобокса (?!!!), то этот комбобокс в режиме "Включая устаревшие" должен иметь логическое поле "Устаревший товар". Это для того, чтобы юзер мог отделить зерна от плевел.
Еще раз повторю, что речь не идет о отображении данных в каком-то конкретном контроле или форме, а речь о переключении РЕЖИМОВ - понимай и реализуй в соответствии с твоей задачей.

для Владимир Саныч:
Владимир СанычЗначит, оно все-таки когда-то обнаруживается...
Ну да. Может обнаружиться и на складе, когда приходят отборщики и говорят, что у них есть товар, похожий на выписанный по накладной, но он всю жисть назывался (приходил в отборных листах) по другому. Типа, это оно теперь и есть?
Владимир СанычА раз так, то почему бы в этот момент не поступить иначе - взять и заменить все вхождения старого кода в таблицах на новый?
Саныч, случаи бывают разные :) В простейшем случае возможно прокатит и такой простецкий вариант, но иногда ведь и не прокатит... Я тонкостей не помню, но вот на вскидку случаи, когда просто изменить ID не прокатит:
1. Товарные остатки хранятся, а не формируются динамически (подход спорный, но здесь не обсуждается). Если у нас есть табличка с товарными остатками, то просто перезаписав ID мы получим попытку нарушения целостности данных - IDшка существует, а мы пытаемся засунуть в эту же таблицу еще одну такую же (ненужную позицию перезаписываем IDшкой старой позиции). Что бы избежать этой радости приходится остаток перекидывать (плюсовать) с остатком "правильной" позиции, а строку с неправильной позицией удалять.
2. ээээээээ... Воспоминания иссякли :) Давненько дело было... Но, помнится, это место (объединение аналогичных товарных позиций) было одним из наиболее сложных участков в том проекте. Можно попробовать поднять архив и покопаться в нем, но ведь и так самостоятельно можно "дофантазировать" :)

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