Доступ иногда переходит к существующей записи при сохранении новой записи-Access2k FE/SQL2005 BE

Это определенно похоже на проблему блокировки записи. Вы используете автономерами как ПК? Вы пробовали 2 компьютера, добавляющих запись в одну и ту же форму одновременно (это означает, что один из них запустит событие insert, в то время как другой добавил новую запись в форму one, но все еще редактирует ее)?

Не могли бы вы проверить тем или иным способом, остается ли PK вставленной записи после вставки в таблице похожим на PK, заданный до вставки (добавив, например, несколько - отладка.печать на вашем коде)?

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

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

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

Вместо этого я использую несвязанный диалог для сбора всех необходимых полей, вставки записи в SQL, а затем открываю основную форму редактирования для этой единственной записи (а не для формы, в которой вся таблица перемещается к только что добавленной записи).

Имейте в виду что в сценарии основной формы / подчиненной формы создание записи в подчиненной форме, когда родительская форма не сохранена, приводит к сохранению родительской записи. Вы можете проверить, есть ли какой-либо код в событиях вставки и обновления основной формы, который вызвал бы запрос основной формы на вставку новой записи (вызванный редактированием подформы).

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

Я видел поведение "как" это, когда есть несколько способов сделать то же самое. (например, выделение вкладки из текстового поля, запускающего lostfocus против нажатия кнопки) поэтому убедитесь, что это не так, если вы этого еще не сделали.

Эта проблема решается триггером репликации слиянием. В этом триггере (эта проблема strart из sql 2005 server , в SQL 2000 server это не НАКе проблемы) репликации вставить некоторые данные в таблицы репликации с идентификаторами и доступ получить это количество идентификаторов вместо реальной формы indentity insert. Я читал, что доступ использует @ @ IDENTITY insetad SCOPE_IDENTITY, и это проблема . Чтобы избежать этого, вы должны изменить триггер слияния таким образом, что в insert trigger on beginning вы сохраните текущее значение из @ @ identity в переменную и в конце триггера вставить значение во временную таблицу как identity с начальным значением того, что записано в переменной. это исправит @ @ iddentity и acces получит правильное значение.

В начале триггера Объявить @identity int Объявить @strsql varchar (128) set @identity=@ @ IDENTITY ar конец что-то вроде set @strsql= 'select identity (int,' +CAST (@identity as varchar (15))+', 1) as id в #temp' exec (@strsql) Эт и он должен быть помещен между если @ @ ошибка Ноль неудача Гото
и возвращение

Проблема в acces будет стираться не только на форме, но и непосредственно в таблице ссылок ODBC.

Я ищу способ, как добавить это автоматически в триггер репликации слиянием (в основном insert).

Это ошибка в доступе и SQL-коммуникации. Доступ возьмите идентичность новой записи из @ @ IDENTITY и когда вы закончите вводить запись, она перезагрузит данные на основе значения из @@IDENTITY value из SQL. В SQL 200 вставленный триггер слияния и доступ обычно работают нормально. Из SQL 2005 триггер слияния имеют некоторую часть, в которой данные вводятся в некоторую таблицу репликации слиянием, которые имеют идентичность и изменяют значение @IDDENTITY формы, что из вновь введенного rcord от доступа.

Одним из решений является chanege все мереге вставляют триггер, чтобы сохранить @IDDENTITY в начале его в переменной и в конце триггера вставляют запись dumy в # temp таблицу как столбец identity с начальным значением переменной, ранее сохраненной.

Это решение я нашел где-то в сети, когда на прошлой неделе меня тоже затронула эта проблема. Я перемещал базу данных из SQL 200 в SQL 2008, а затем обнаружил эту проблему с идентификацией в Access. Я подозреваю репликацию, потому что когда я удалял одну из подписок, все начинало работать ну а после воссоздания его снова стерли.

Я использую это для решения задачи (такем откуда-то в сети).

В начале триггера вставки слияния

Объявить @identity int

Объявить @strsql varchar (128)

Set @identity=@@IDENTITY

И в конце слияния вставить триггер

Set @strsql= 'select identity (int,' +CAST(@identity as varchar (15))+', 1) as id в #temp '

Exec (@strsql)

Последний код должен быть помещен на место / * вставить конец на этом месте */ в коде репликации слиянием

Если @ @ ошибка 0

Goto FAILURE

/ * вставить конец на это место * /

Возврат

Но я ищу способ сделать это автоматически для всех существующих триггеров слияния при публикации и для всех существующих триггеров слияния при существующих и будущих подписках.

0I нашел это

Http://jagbarcelo.blogspot.com/search/label/identity

Но я не знаю, Могу ли я использовать его на SQL 2008.