прошу прощения, был очень занят :)

кошмар, как все в твоей базе напутано...
1. #Name означает, что название поля, на которое ты сослался в источнике контрола, не найдено среди полей рекордсета-источника формы.
- вместо trelLPTLEG.memREMARK ("Примечание" верхнее) нужно memREMARK_LEG,
- вместо trelLPTDET.memREMARK ("Примечание" нижнее) - memREMARK_DET,
- вместо chrTAXON_TABL ("Комбинация") - idsTAXON_TABL_ID.

2. Сообщение "Введенное значение не подходит для данного поля. ..." не может не выскакивать, потому что источником для контрола (возьмем, к примеру контрол "Точка") назначено текстовое поле (для "Точки" - chrPOINT_LEG_TABL_DESCRIPTION), а ввод данных в контрол осуществляется на основе комбобокса-справочника, возвращающего числовое значение.
И таких контролов у тебя там много... штуки три...

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

При организации ввода на основе комбобокса-справочника нужно организовывать ввод/обновление ТОГО поля, которое содержит ССЫЛКУ на позицию справочника. В твоем примере источником контрола
- "Точка" должно быть поле idsPOINT_LEG_TABL_ID из таблицы trelLPTLEG (это поле надо добавить в запрос-источник формы), так как это ссылка на позицию справочника.

3. В таблице POINT_LEG_TABL у тебя каждая точка имеет ссылку на район, в котором находится (табл. DISTRICT_TABL), а район, соответственно, -на область (PROVINCE_TABL). Таким образом, изменение в контроле "Точка" автоматом влечет изменение в контролах "Район" и "Область" (только нужно их обновить).
Если преобразовать эти контролы ("район" и "область") в текст-боксы, оставив их источники данных в таком виде, как сейчас, то пользователь сможет редактировать их текущее значение, то есть править запись справочника.
Если оставить контролы "Район" и "Область" в виде комбобоксов (поменяв поле в источнике данных на правильное - по аналогии с контролом "точка"), то пользователь сможет перевести любую точку в любой район, а любой район - в любую область.
Так себе работа с данными получается. Но все это возможно только при использовании несогласованного набора данных, так что еще вот еще один довод в пользу того, чтоб не спешить с ним.

4. Рекордсет станет обновляемым, если ты удалишь из запроса таблицы PROVINCE_TABL и DISTRICT_TABL. Впрочем, надо сперва понять логику действий, совершаемых через форму - тогда и с набором таблиц определяться.

5. У тебя в тексте названия точки содержатся заодно и район, и область. Зачем такое дублирование, если есть отдельные справочники?

6. Какая странная схема данных...

Тебе никто не смог помочь потому, что ты очень усложнил оказание помощи. Мне, например, пришлось специально искать и устанавливать Тотал Коммандер.

И вообще, у тебя сравнительно простая задача, но ты ее максимально запутал...

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

Ты можешь создать файл в MS Visio и взять в него структуру твоей БД? А потом положить этот файл сюда. Только с пояснениями, что каждая таблица содержит...

Ты базу сам с нуля создавал или переделываешь чужую?

Форму, которую мы обсуждали, сам делал или она чужая? Насколько критично, чтоб форма была организована именно так, как у тебя: с кучей кнопок, в том числе с переделанной навигацией по записям?

Посмотри прикрепленную базу.
Элементы формы cboProvince и cboDistrict я сделал несвязанными.
Источник записей для cboDistrict ограничивается выбранным значением элемента cboProvince, а для cboPointLeg - выбранным значением элемента cboDistrict.
Добавил события cboProvince_AfterUpdate и cboDistrict_AfterUpdate.
Также добавил событие cboPointLeg_DblClick, которое, помимо двойного щелчка, вызывается еще и переходом по записям из события Form_Current.

По-хорошему из названия точки, хранящегося в таблице, все же нужно убрать название области и района. А в источнике записей элемента cboPointLeg тогда можно сделать запрос, который соберет тебе нужную строку, взяв данные из трех таблиц: область, район и точку. Только тогда нужно чуть поразвернутей незвать области в таблице PROVINCE_TABL.

MS Visio содержится в английской версии пакета MS Office 2003. В принципе, легко можно поставить как отдельный продукт. Среди прочего Визио позволяет взять структуру из базы МДБ или с SQL-сервера. Удобно для анализа этой самой структуры. Возможно создание базы из структуры файла Визио, но это, если я правильно помню, требует установки Visual Studio.
Визио, ессесно, не единственный подобный продукт.

Насчет базы спросил потому, что схема данных (тот фрагмент, что есть в твоем примере) содержит дубли таблиц. А зачем, я не понял.

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

Если произошло какое-либо изменение данных в форме, то ее свойство Dirty становится True (Me.Dirty=True). Его и можно использовать, чтоб проверять, вносились ли изменения.

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