Нет, нет. Не так. Предопределенный реквизит "Код" в справочниках и поле ID в таблицах базы (внутренний код), по которому организованы связки между ключевыми полями - это разные вещи.<br>Вот смотрите, пример, который покажет что при подмене dbf-а будет проблема:<br>Пусть в базе данных имеется сотрудник, для которого заданы сведения о его праве на налоговые вычеты:<br><br>Справочник.Сотрудники<br>Код=00000165, Наименование=Иванов Иван Иванович<br><br>Справочник.ВычетыСотрудниковПоНДФЛ<br>Запись 1:<br>ВидВычета=400 рублей на налогоплательщика с 01.01.2008 г. (код НДФЛ = 103)<br>Запись 2:<br>ВидВычета=на ребенка-инвалида одинокому родителю с 01.01.2008 г. (код НДФЛ=107 до 2009 г., код НДФЛ=112 с 2009 г.)<br><br>Соответственно, Справочник.ВидыВычетов<br>Запись 1:<br>Код=103, Наименование=400 рублей на налогоплательщика<br>Запись 2:<br>Код=112107, Наименование=4000 руб. на каждого ребенка-инвалида до 18 лет, единственному родителю и др.<br><br>Теперь смотрим на уровне файлов как реализованы связи.<br>Справочник.Сотрудники - файл SC16.dbf (имя файла может быть другим)<br>ID=LJ - внутренний код. На уровне пользователя и конфигурирования его не увидеть никак. Обратите внимание, что именно он является средством для установки связей между таблицами баз, а вовсе не тот код, который мы видем в справочнике, то есть, вовсе не "00000165".<br>PARENTID=K6 - ссылка на группу, являющуюся "Родителем" данного элемента справочника. Интересно то, что если указать в качестве родителя ссылку "на самого себя", то такая ошибка классифицируется как "неисправимая ошибка базы данных" и не исправляется автоматом через конфигуратор, хотя ничего сложного в том, чтобы поставить ссылку в корневой уровень нет (это разработчикам).<br>CODE=00000165<br>DESCR=Иванов Иван Иванович<br><br>Справочник.ВидыВычетов<br>Запись 1:<br>ID = 3 - вот он код, по которому будет ссылка установлена в таблицах базы, а не "103"<br>CODE = 103<br>DESCR = 400 руб. на налогоплательщика, пп.3 п.1 ст.218 НК<br>Запись 2:<br>ID = K<br>CODE = 112107<br>DESCR = 4000 руб. на каждого ребенка-инвалида до 18 лет, единственному родителю и др.<br><br>Справочник.ВычетыСотрудниковПоНДФЛ<br>Запись 1:<br>ID = пуст! Поле есть, а значения не будет, так как в конфигураторе указано, что коды в данном справочнике не нужны.<br>SP1052 = 01.01.2008 - это дата начала, идентификатор поля dbf таблицы может быть иным.<br>SP1054 = 3 - это ссылка на запись таблицы "ВидыВычетов", причем указано значение не "103", а ID записи, то есть 3, это важно.<br>Запись 2:<br>SP1052 = 01.01.2008<br>SP1054 = K<br><br>А теперь возьмем dbf, соответствующий справочнику ВидыВычетов из другой такой же базы. Даже из такого же релиза. И мы там увидим, что ID в dbf-е вовсе не такие как тут!<br>Справочник.ВидыВычетов<br>Запись 1:<br>ID = 4<br>CODE = 103<br>DESCR = 400 руб. на налогоплательщика, пп.3 п.1 ст.218 НК<br>Запись 2:<br>ID = J<br>CODE = 112107<br>DESCR = 4000 руб. на каждого ребенка-инвалида до 18 лет, единственному родителю и др.<br>Запись 3:<br>ID = 3<br>CODE = 105<br>DESCR = 3000 рублей на налогоплательщика, относящегося к категориям пп. 1 п. 1 ст. 218 НК РФ<br>Запись 4:<br>ID = K<br>CODE = 507<br>DESCR = Вычет из суммы помощи полученных ветеранами, инвалидами ВОВ и приравненных к ним<br><br>Причем это не с потолка взято, я смотрю в реальные файлы баз данных. Одна из них - обновляется с января 2003 года, а вторая = установленная пустышка.<br>Подменив файл, мы получим, что ссылки в справочнике "ВычетыСотрудниковПоНДФЛ" будут указаны совсем на другие элементы справочника "ВидыВычетов", а часть их вообще окажется "битыми". И это потому, что на самом деле "ссылочный механизм" работает не по кодам, а по внутренним кодам.<br>Вот вы пишете:<br>> А кто что еще навводил (с ДРУГИМИ кодами) - кому это мешает выбрать СТАНДАРТНЫЙ<br>В той базе, в которую я смотрю никто ничего не менял. Она чистая "типовушка", но установленная давно и обновленная раз 20, а вторая - тот же текущий релиз, но установленный с дистрибутива сегодня. Мы же не знаем какая рабочая база у того, кто задавал вопрос. Когда ее ставили? Делали ли в ней что то на уровне конфигурирования? Обновляли ли ее?<br><br>одновременный ответ и для Alexandr VA<br>Обработка, которую я на файлообменник положил задумана была для того чтобы помочь человеку решить его проблему. Я не понял фразу, которую она написала<br>> Не обновляется справочник Виды вычетов, пустые клетки, редактировать не дает<br>Подумал о том, что справочник у нее, возможно не пуст и она может перемещатся по форме списка и в вертикальном направлении. Такое возможно, когда элементы в справочнике есть, но наименования и прочие реквизиты визуализации пусты, а поскольку мы не знаем как ее базу поставили, такая ситуация не исключена. Поэтому я сделал так: проверил есть ли у нее в справочнике хоть какие то элементы. Если нет, то запускал алгоритм создания элементов, который просто взял в обработке ОбновлениеИБ и это бы сразу решило ее проблему. Но если элементы там уже есть?! (вот почему не стоит использовать tranref, ведь мы не знаем пуст ли справочник на самом деле, возможно просто убиты реквизиты Код, Наименование и т.п.) И вдруг относительно этих реквизитов описаны права на вычеты 3000 человек? Вы хотите ее заставить заново их описывать? Лучше уж пусть моя обработка скажет, что элементы там уже есть и тогда я бы сделал вторую, которая разобралась бы с тем относительно каких испорченных элементов построены связи и воссоздала бы их наименования, а уж потом дополнила справочник недостающими элементами, которые появились с релиза 288