Подтвердить что ты не робот

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

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

У меня есть база данных Access, в которой я недавно переносил таблицы в SQL 2005, Access продолжает функционировать для пользователей как интерфейс, предоставляющий формы, отчеты и запросы.

Однако, начиная с перехода к настройке доступа FE/SQL BE, пользователи сообщали, что иногда, когда они вводят новую запись, они нажимают на подформацию (сохраняя запись) или нажимают на сохранение в самом меню, он переходит к существующей записи. Новая запись была сохранена, но по какой-либо причине доступ переключается на другую запись по мере ее обновления. Затем пользователь должен закрыть, найти сохраненную запись и продолжить ее редактирование.

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

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

Я заметил, что это происходит только в формах, которые имеют подчиненные формы, поэтому моя первая мысль заключается в том, что это связано с доступом, отправляемым через данные подформы до сохранения данных формы, что вызывает нарушение PK. Но это, похоже, не происходит: на сервере SQL нет ошибок, и запись успешно сохраняется. Заставляя пользователей сохранять основную запись формы перед добавлением записей подформ (т.е. На цитату, заставляя их сохранять цитату, прежде чем добавлять строки), не работает, она просто вызывает скачок (иногда) при сохранении.

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

Сервер, на котором запущены таблицы, - это SQL Server 2005, пользователи используют сочетание Access 2000 и 2003, в основном XP SP3 с несколькими старыми блоками Win2k. Они используют репликацию Merge, а несколько пользователей запускают реплицированные версии SSEE2005 и подписываются на основной сервер. Большинство пользователей не реплицируются, просто подключаясь непосредственно к серверу через собственные клиентские соединения ODBC или SQL. Но я проверял, что это происходит со всеми пользователями, обычно один или два раза в день, и это случилось со мной раньше. Так что это не проблема пользователя.

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

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

Update: (1/10/09) Проблема решена, благодаря Дэвиду Фентону. Установка формы в режим ввода данных (Form.DataEntry = true), прежде чем открывать ее для добавления записей, действительно препятствует прыжкам. Клиент не сообщает никаких проблем, так как я изменил это неделю назад.

4b9b3361

ОТВЕТЫ

Ответ 1

Клиент периодически сталкивается с подобными проблемами. Это началось сразу же после того, как они начали использовать репликацию слиянием.

Я сообщил о нескольких контактах в группе продуктов Microsoft Access, а также о моих MVP файлах Access и SQL Server.

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

BTW превосходная съемка и подробное описание проблемы.

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Ответ 5

Эта проблема рассматривается при запуске репликации слиянием. В этом триггере (эта проблема связана с сервером sql 2005, на сервере SQL 2000 это не вызывает проблем) репликация вставляет некоторые данные в таблицы репликации с идентификаторами, а доступ получает это число идентичности, а не вставляет реальную форму вставки indentity. Я прочитал, что использование доступа @@IDENTITY insetad для SCOPE_IDENTITY и это проблема. Чтобы этого избежать, вы должны сменить триггер слияния таким образом, чтобы при вставке триггера вы возвращали текущее значение из идентификатора @@в переменной и в конце значения триггера в таблице temp как идентификатор с начальным значением того, что написано в переменной. это исправит @@iddentity и acces получит правильное значение.

при запуске триггера  DECLARE @identity int  DECLARE @strsql varchar (128)  set @identity = @@IDENTITY ar end что-то вроде  set @strsql = 'select identity (int,' + CAST (@identity как varchar (15)) + ', 1) как id в #temp'  Exec (@strsql) et и он должен быть помещен между   если @@error < > 0       goto FAILURE
а также   вернуться

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

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

Ответ 6

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

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

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

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

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

DECLARE @identity int

DECLARE @strsql varchar (128)

set @identity = @@IDENTITY

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

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

Exec (@strsql)

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

если @@error < > 0

goto FAILURE

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

возврат

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