Помогите исправить индекс или ключ не может содержать пустое значение

Помогите исправить индекс или ключ не может содержать пустое значение (Null) в двух таблицах плановые рабочие дни и состояние штата,

Вложения

Database4.rar (27.0 Кб, 26 просмотров)

0

mobile, а в форме разве не одну только запись видно?
Соответственно не 1000 записей обрабатывается, а только 1.
Вот если табличного вида, то возможно и да, но как правильно заметили при нынешних скоростях навряд ли повлияет.
Или тут еще какие хитрости ленты присутствуют?

0

Сообщение от LyPUH mobile, а в форме разве не одну только запись видно?

Немного о другом разговор. Одна запись или много это иной процесс. Вот для интереса сделай форму с множеством полей со списком с тяжелыми источниками и попробуй открыть ее. Когда этих полей пару десятков, то форма открывается очень тяжело. Также и с таблицами и их экранным представлением. Когда полей подстановок много и запросы-источники тяжелые, то даташит (экранное представление таблицы, запроса, табличной формы) тоже открывается со скрипом.

2

Сообщение от mobile Об открытии формы с источником, запросе, таблицы на раб.столе. Вы утверждаете, что поля подстановки никак не влияют на время открытия.

При открытии таблицы или запроса для просмотра - конечно, влияет. Да только кто ж их открывает-то в готовой рабочей базе? Если база уже готова - то для пользователей есть формы и отчеты.

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

0

Сообщение от texnik-san А вот каким образом подстановка таблицы вдруг станет влиять на форму с источником - я не понимаю. У формы источник такой, каким я его сконструировала.

Запрос по возможности наследует свойства исходной таблицы. В том числе и подстановки если они есть. Конечно, если Вы измените свойства в форме, то наследования не будет. А иначе подстановки останутся такими же как в оригинальной таблице

0

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

Миниатюры

 

0

Сообщение от Оля1231 в таблице состояние штата тоже нужен год и месяц

Нет, не нужен. Эта информация есть в связанной таблице - объединяйте эти две таблицы в запросе и получайте сведения о годе и месяце. Дублировать поля из одной связанной таблицы в другую - нарушение нормализации.

Добавлено через 2 минуты

Сообщение от Оля1231 вот так в задании нужно чтобы выглядела схема

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

Добавлено через 16 минут

Сообщение от mobile Запрос по возможности наследует свойства исходной таблицы. В том числе и подстановки если они есть.

Вы имеете в виду экранное представление запроса. Я уже давно не спорю с этим, но, повторяюсь, в готовом приложении пользователи не работают с экранными представлениями запросов и таблиц.

Сообщение от mobile Конечно, если Вы измените свойства в форме, то наследования не будет. А иначе подстановки останутся такими же как в оригинальной таблице

Давайте, чтобы не обсуждать сферических коней в вакууме, возьмем конкретный пример. Вот есть база, в тей, в таблице TAB, есть подстановки.

Форма Запрос1 основана на запросе Запрос1, который, если его открывать для просмотра, разумеется наследует подстановки у таблицы TAB.

Тем не менее я не вижу ни единой причины подставновкам, имеющимся в таблице TAB, хоть каким-либо образом влиять на работу формы Запрос1, в том числе на скорость ее загрузки. Если вы видите такие причины - рассказывайте. Возможно я чего-то недопонимаю.

0

Вот база:

Вложения

sample.rar (65.5 Кб, 5 просмотров)

0

Прошу также обратить внимание, что я не меняла никаких свойств на форме. Я просто вывожу на ней не все поля, имеющиеся в запросе - источнике.

0

Оля1231, запрос, о котором я говорила, может быть примерно таким, как в приложенной базе. Так и информация о годе и месяце есть, и ключа по двум полям нет.

Вложения

Database4_1.rar (31.4 Кб, 3 просмотров)

0

texnik-san, Ваш пример как раз хорошая иллюстрация к тому, что говорил:

Сообщение от mobile С моей точки зрения безусловно замедляют. Хотя при нынешних мощностях ПК это может быть и незаметно. Но если хорошенько нагрузить множество полей сложными источниками, будет хорошо заметно. Также как и в форме, где обилие полей со списком утяжеляют форму.

Сообщение от mobile Вот для интереса сделай форму с множеством полей со списком с тяжелыми источниками и попробуй открыть ее. Когда этих полей пару десятков, то форма открывается очень тяжело.

Сообщение от mobile Конечно, если Вы измените свойства в форме, то наследования не будет. А иначе подстановки останутся такими же как в оригинальной таблице

В Вашей форме изменены свойства полей. Вместо комбо текстовые поля. Полей со списком в Запрос1 всего 3 и они простенькие по нескольку строк. Разумеется Вы не увидите простоев на современной технике. Хотите увидеть - создайте таблицу со многими сложными подстановками, где в источнике тяжелые запросы. Да можно и без таблицы, достаточно на форме сделать множество комбо со сложными, тяжелыми источниками. Она будет долго грузится.
Я видел пример где на форме было около 40 или 50 полей со списком и списков. Грузилась она несколько минут. Но создатель уверял, что только так и надо...

0

Сообщение от mobile В Вашей форме изменены свойства полей. Вместо комбо текстовые поля.

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

И я всегда только так и создаю ленточные формы.

Поля со списком у меня в единичных - и там они
1) нужны
2) ничего не замедляют (источник строк единичной формы содержит одну запись)
3) как раз очень удобно наследовать подстановки из таблицы. Ускоряет процесс создания форм. Потому что к одной и той же таблице форм различных может быть очень много. Чем много раз повторять настройку полей - гораздо быстрее и поще наследовать подстановку таблицы.

Добавлено через 6 минут

Сообщение от mobile Я видел пример где на форме было около 40 или 50 полей со списком и списков. Грузилась она несколько минут. Но создатель уверял, что только так и надо...

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

Подстановка в таблице - это просто инструмент. Как и всякий инструмент, он требует умения им пользоваться и осознанности,чтобы отличать ситуации, в которых он во благо, от тех, в которых он во вред.

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

0

Сообщение от mobile Ведь поля подстановки те же самые комбо с sql-источником, набирающие данные только во время открытия.

А может выложить базку в 2GB размером -на 8-9 лимонов записей - пусть молодёжь тренируется с подставниками? ...

0

Eugene-LS, из того, что подстановка вредна в конкретной очень большой базе - следует, что она "абсолютное зло" и вредна всегда?

0

Сообщение от texnik-san следует, что она "абсолютное зло" и вредна всегда?

Ни я, ни Eugene-LS не объявляли подстановки "абсолютным злом". Это Ваши фобии. Я вообще редко применяю квантор всеобщности, всегда находится какой-нибудь юпитер которому дозволено запрещенное остальным быкам.

И на этом позвольте откланяться. В таком тоне диалог не получиться. Вам сегодня отказывает обычная легкость соображения и Вы не хотите/не можете слушать (слышать) другие аргументы. Хотя я точно ничего не говорил о зле подстановок. Тема была иная.

1

Сообщение от texnik-san из того, что подстановка вредна в конкретной очень большой базе - следует, что она "абсолютное зло" и вредна всегда?

Нет не следует. На относительно небольших обьёмах данных - вперёд!
Если уж приспичило.
Ну может я стар и чего не понимаю, но в моих приложениях пользователь не имеет прямого доступа к таблицам (вообще), - следовательно подстановки там не имеют никакого смысла изначально.
И всё как то "крутится" на формах и формах ....
Успехов!

Добавлено через 3 часа 0 минут

Сообщение от mobile Я вообще редко применяю квантор всеобщности, всегда находится какой-нибудь юпитер которому дозволено запрещенное остальным быкам.

Это надо записать текстовичком - в папку "Нехренаськи" ....
Круто сформулировал!

0

Сообщение от mobile Ни я, ни Eugene-LS не объявляли подстановки "абсолютным злом".

Боже упаси, вы конечно нет. А Евгений - да:

Сообщение от Eugene-LS грубейшая ошибка использовать подстановки

Причем еще утверждал, что если подстановки убрать - то у девушки ее проблема решится. А проблема у нее совсем не в подстановках, а в составных ключах, в одной таблице по 2м, в другой - по 6 или 7 полям.

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

0

Сообщение от texnik-san НО, скажем, я не вхожу в секту тех, кто считает поля подстановок в таблицах преступлением,

головой об стенку биться - это не преступление, это просто пример идиотизма и не более

0