Для сохранении табеля текущего месяца в единую таблицу "истории табелей" какой составной индекс создать?
Запись в табеле характеризуется:
1. Код сотрудника (уникален)
2. Код проекта (уникален для таблицы проектов, но сотрудник может участвовать в нескольких проектах,
проекты могут изменяться, добавляться, прерываться в середине месяца), кстати, проекта может вообще не быть (тогда я ему
присваиваю код сотрудника со знаком минус).
3. Месяц в году.
4. Год.

С удалением "ошибочно введеных сотрудников или контрактов" вроде бы ясно. Это удаление должна обеспечить схема данных.

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

bubucha,

Если можно, то кратко поясните некорректность и как разрешать проблему.

Ведь создав такой индекс, по-моему легко проверять есть ли такая запись в текущем месяце или прошлых.

А иначе как? Писать сложный условный оператор на проверку совпадения четырех полей? Или это делается легко доступными средствами? Какой путь правильный?

ROI,
Будьте так любезны, если можно, подробнее изложите "как делаете" и "что нарушаете"

Кажется нашел: https://www.sql.ru/forum/674432/zapros-na-ne-sovpadaushhie-zapisi#

ROI, Спасибо.

bubucha
зы а чем вызвана необходимость отдельной таблицы истории?

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

Выкладываю усеченную базу.
Об индексе уже речи нет. Подробные комментарии в форме (в базе).
Уперся в сообщение: Run-time error '3072':
"Недопустимый аргумент функции"

Сообщение выходит при попытке выполнить запрос поиска записей в истории, соответствующих вновь прибывшему сотруднику или новому проекту в данном месяце (июль 2019). Вроде бы сравниваю только числовые поля (не текстовые) как рекомендует Help.

Если условие отбора не ставить (см. базу), то ошибка не выходит.
Проконсультируйте пожалуйста.

Игорь С,
Да еще следует добавить, что подсчет записей в запросе выполняется функцией
Me.fld1 = Nz(DCount("*", "QPC_ProjectForContractorsALL_Select")) См. базу

Игорь С,
И еще: при инициализации глобальных переменных запрос "... _Select" в виде таблицы правильно показывает одну запись, которую нужно добавить.

sdkuВопрос ТСа касается структуры БД и таблиц в ней.Считаю что не видя БД и не зная какие задачи решаются ответить на вопрос ТСа навряд ли возможно.

Базу выложил, если можно гляньте "одним глазом".

bubuchaИз описания я могу нафантазировать следующее: сотрудник в определенный период времени участвует (или не участвует) в том или ином проекте. Как мне видится, период его участия - это именно интервал С и ПО , а не просто месяц.
Как сотрудник попадает(выбывает) в проект? Наверняка есть некий документ, который этот факт фиксирует. Это я к тому, что я бы сохранял именно документы, а табель это уже как производная от этих документов...если конечно сам табель не является документом. Это только самая банальная фантазия, по факту у вас все может быть не так.

Все правильно, этот Аксессовский табель и есть документ. В нем фиксируется проект С и ПО для соответствующих сотрудников и на них сносятся затраты в соответствующие даты.
Переделки потребовались, когда один сотрудник начал работать над несколькими проектами, кроме того оказалось, что проекты могут начинаться в середине месяца, и сотрудники могут наниматься и увольняться в середине месяца.

А требуется почасовый учет трудозатрат.

sdkuИгорь СБазу выложил, если можно гляньте "одним глазом".Не открывает-пишет нераспознаваемый формат
может сохраните до А-2007?
Так база выложена в формате accdb. Странслирована 2010-м.

Пробовал и в 97-м и 2003-м. Они просто на вычислении функции DCount("*" ... выгружаются.

Сейчас вычистил модули Global - оставил две функции f_nYear() и f_nMonth() и в модуле DateProcess оставил одну функцию.
Все то же самое.

Там у меня одно изобретение: в запросе QPC_ProjectForContractorsNo коду проекта (Cod_Proj: -[Account data]!COD) присваивается значение кода сотрудника с минусом (проекта нет, но желателен уникальный код). Вроде бы получается уникальное целое число..., но как оно может повлиять.

Еще более упростил файл "базы". Убрал все лишние функции в модулях.
Быть может кто-нибудь поможет.

sdkuDcount работал на ура еще до 97

Все когда-то работает, а иногда сбоит.

sdkuвсе то же самое-нераспознаваемый формат
(а у кого-нибудь открывается-может преобразуете)
21927397

Уважаемый sdku.
Я не понял. У меня используются только целые числа. Здесь нет неточных операций.
Поясните, если можно подробнее, что Вы имеете в виду.

Глубокоуважаемый sdku, спасибо, но,
- этот файл табеля мною уже полтора года как (03.01.18) скачан и просмотрен. Есть и другие табеля;
- я уже давно, никогда не грешу на стандартные функции (еще со времен Фортрана 77).

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

Уважаемый sdku,
Выкладываю результаты "исследования"
Проблема: Табель учета рабочего времени в месяце.
Записям в табеле соответствует сотрудники и проекты, по которым он работает (т.е. у одному сотруднику могут соответствовать несколько записей (проектов)), имеются также сотрудники "без проектов".

Задача: в таблицу табеля текущего месяца (который начал уже заполняться)
добавить запись вновь прибывшего сотрудника с назначенным ему проектом,
или назначить проект сотруднику,
или добавить сотруднику еще один проект (или не один),
или добавить сотрудника без проекта.

Т.е. имеется задача поиска отсутствия комбинации двух целочисленных параметров (кодов) в таблице.
Задача кода проекта для сотрудника без проекта решена путем присвоения коду его проекта кода этого сотрудника со знаком минус.

На форуме мне предложили подобное решение см. файл базы:



Оно хотя и работало в режиме таблицы, но давало ошибку при подсчете записей в этом запросе с помощью DCount("*" ...
В результате был найден (подсказали) запрос с предложением INNER JOIN, а именно для данного случая:



Также рассмотрены варианты (работающие быстрее) с предложением LEFT JOIN, работающие при условии сброса данных одного из запросов в промежуточную таблицу.
Файл базы с комментариями и функционалом прилагается.
Причина не работоспособности первого запроса не выяснена.