Артём Каретников

FOR ... EACH

Доброго. Для работы с элементами есть FOR Each ... IN.

Значит, на пустое поле так не проверяют. Надо понимать разницу между "пустая строка" и Null

самое простое для акцесса - это прибавлять к строке пустую, тогда NULL станет тоже строкой.

MyValue = trim(MyValue) & ""

что здесь делается - если значение строки MyValue - одни пробелы, оно провратится в ""
Если значение строки NULL - оно провратится в ""

select * from mytable where trim(MyValue) & "" <> "" -- вот этот запрос отработает.

Теперь, две таблицы:

select * from mytable mt
join mytable2 mt2 on mt.id = mt2.id_item
where trim(mt.MyValue) & "" <> ""

если надо делать быстро - акцесс тут тоже не очень подойдет. Ничего серьезного в этой задаче нет, конечно.
я бы поставил бесплатную версию sql сервера, загнал все в одну таблицу и дал бы признак Department
и в него ваши филиалы от 1 до 100.

А дальше простой селект. Должно летать и ничего сложного не будет.

Вот я примерно об этом вам только что и писал. Подход странный.
Вы меняете или добавляете в один момент - одну запись. Одну. Нахрена писать их все?
Ловим событие after_update комбобокса с оценками. И вставляем/обновляем запись. Одну. Не забудьте проверять, что заполнены комбобоксы Grade, Subject, Student.

Это если очень хочется кодом. А ведь это же самое можно сделать вообще код не используя.

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

Т.е. уже по описанию задачи видно, что вы делаете ее не очень правильно, имхо.

Почему бы не передать это профессионалам? Будет значительно быстрей, равно как можете попросить прокомментировать решение.

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

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

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

Ай вэй... Вообще детский вопрос. Реализовать его можно минимум тремя вариантами.

Я лично, чтобы руку не сбивать, передаю через параметры формы.
' собираю строку для передачи в форму для редактирования
strOpenParam = me.txt_id & "#"
DoCmd.OpenForm "frmLocationAddEdit", acNormal, , , , acDialog, strOpenParam

Где me.txt_id - то самое поле. А "#" - разделитель.
Если надо еще параметров - передаешь их таким же образом, добавляя разделитель.

И в форме 2 делаешь вот это:

Private Sub Form_Open(Cancel As Integer)
Dim searchArgument As String
searchArgument = Nz(OpenArgs, "")
If Len(searchArgument) = 0 Then
MsgBox "The open arguments are not correctly transferred ", vbInformation
Cancel = True
Exit Sub
End If
me.id_form = Split(OpenArgs, "#")(0)

У этого метода есть один, но серьезный недостаток. Разделитель, в данном случае # не должен присутствовать в переданной строке. Поэтому для себя выбери разделитель другой - и контролируй передаваемую строку перед тем, как, открывать вторую форму.
Достоинство его - удобно передавать кучу данных сразу, наглядно.

Доброго.
В такой постановке: 1 вариант прост и не требует дополнительных телодвижений. Что в нем не нравится, зачем нужен второй?

Меня лично смущает: "к полю в акцессе". А почему, собственно, не сделать stored procedure с параметрами, из акцесса формировать строку, и выполнять вообще всё, а не конкретно апдейт одного поля, на стороне сервера?

Конечно. before_update событие для этого предназначено.

Конечно, он недоступен, потому что в обоих случаях первичный ключ. Зачем в таблице Общая - такой сложный составной первичный ключ? Зачем в ней же тип оборудования уже есть - но еще и ссылка на таблицу типа оборудования?
Как минимум это - лишнее. У вас в таблице "общая" поле Код_ТО должно быть не первичным ключем. Поле "тип оборудования" - вообще к аллаху, его не нужно, потому что на него будет ссылка.

В таблице "тип оборудования" - поле тип оборудования - тоже не должно быть первичным ключем. А вот Код_ТО - это первичный ключ однозначно. И вот его берете мышой и швыряете на таблицу "Общая" - тогда у вас как раз создастся тип "один ко многим".
Сама схема данных... Оставляет желать, конечно, лучшего. Почему в "выезде" - код_ремонтника - не первичный ключ, а ремонтник, т.е. текстовое поле с фамилией именем, первичный? Должно быть с точностью до наоборот.
Зачем в депо код депо - не первичный ключ, а первичным ключем сделаны Название_Депо и Код_ВРК? И так далее.

Не бывает чудес, Золушка. А это именно чудо, а скорее - невнимательность. Скопирована, например, не база, а линк на нее. Или при открытии базы данных выбираете одну, а полагаете, что другую.

Хотя есть еще один вариант, вполне вероятный. Если есть третья база, в которой собственно хранятся значения и она прилинкована как источник данных. Скриншот с окна с таблицами нужен, там это сразу видно.

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