В дополнение к использованию # delimeters вокруг даты, как упомянуто klabranche, вы также должны использовать однозначный формат даты. Либо используйте стандарт ISO гггг-мм-дд, используя формат (Jobdate, "гггг-мм-дд"), либо см. Даты возврата в формате США # мм / дд / гггг #
Дважды проверьте, что вы используете кавычки вокруг тестовых полей и нет кавычек вокруг числовых полей. ProjectID может быть числовым или текстовым.
Я бы переименовал поля text43 и test48 в форме, чтобы было яснее, что они собой представляют. Предполагая, что это связанная форма, вы можете присвоить им то же имя, что и поле.
Вам не нужно использовать свойство .Value.
Проблема с DoCmd.RunSQL заключается в том, что он игнорирует любые ошибки. Любое из следующего покажет любые сообщения об ошибках, полученные запросом. При использовании DAO используйте Currentdb.Execute strSQL, dbfailonerror. Для ADO используйте CurrentProject.Connection.Execute strCommand, lngRecordsActed, adCmdText. Затем можно удалить строки docmd.setwarnings, если они есть.
Если вы собираетесь использовать docmd.setwarnings, убедитесь, что вы добавили выражение True также в любой код обработки ошибок. В противном случае странные вещи могут произойти позже, особенно когда вы работаете над приложением. Например, вы больше не будете получать сообщение «Вы хотите сохранить свои изменения», если закроете объект. Это может означать, что нежелательные изменения, удаления или добавления будут сохранены на вашем MDB.
Кроме того, производительность может существенно отличаться между двумя методами. В одной публикации сообщалось, что currentdb.execute занял две секунды, а docmd.runsql - восемь секунд. Как всегда YMMV.
У HansUp есть отличная точка зрения на использование зарезервированных имен полей. Посетите Соглашения Тони о таблицах и именах полей