«Системный ресурс превышен» при обновлении набора записей и, возможно, в других точках

Question

У меня возникает прерывистая проблема с приложением Excel 2010 front-end, Access 2010. Он используется 5-10 пользователями одновременно. В последнее время пользователи начали периодически получать следующее сообщение об ошибке:

Run-time error '3035': System resource exceeded.

Иногда кнопка Debug недоступна, так что я не могу перейти к коду, который вызвал ошибку, но когда он доступен кликать, он принимает мне на следующий код:

'Open connection to back end DB 
Set db = OpenDatabase(dbPath) 

'Open a recordset of a table 
Set RS = db.OpenRecordset(Tbl) 

'loop through rows in a 2D array 
For i = FR To LR 
    RS.AddNew 
    'loop through columns of the 2D array 
    For j = 1 to LC 
    'set values for various fields in the new record, using values from the array 
    Next 
    RS.Update 
Next 

в данном случае RS.Update помечается как линия, которая вызывает ошибку.

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

Один из вопросов может быть размером с обратным концом доступа; в настоящее время ~ 650 МБ, и мы не начали получать эти сообщения, пока не выросли до 600 МБ.

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

Answer 1

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

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

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

Сохранение этого соединения также будет по существу increase the performance of your data access.

Edit:

Вы должны быть более четко при использовании набора записей и точно указать режим работы вам нужно:

Set RS = db.OpenRecordset(Tbl, dbOpenTable, dbFailOnError) 

или быстрее, если вы только добавления данных:

Set RS = db.OpenRecordset(Tbl, dbOpenTable, dbAppendOnly + dbFailOnError) 

Также убедитесь, что вы закрыли набор записей, как только закончите с добавлением данных !:

Set RS = db.OpenRecordset(Tbl, dbOpenTable, dbAppendOnly + dbFailOnError) 
    With RS 
     'loop through rows in a 2D array 
     For i = FR To LR 
      .AddNew 
       'loop through columns of the 2D array 
       For j = 1 To LC 
       'set values for various fields in the new record, 
       'using values from the array 
       Next 
      .Update 
     Next 
     .Close 
    End With 
    Set RS = Nothing 

Answer 2

Это связано с исчерпанием доступной виртуальной памяти (виртуальной машины) или диска подкачки. 32-битное приложение не может использовать более 2 ГБ, и по какой-то причине Access использует много виртуальных машин, и когда ему нужно больше и не может получить их, тогда у вас заканчиваются системные ресурсы.

Решение состоит в том, чтобы убедиться, что ваша виртуальная машина находится как минимум в 4 раза больше ОЗУ и перезагружать компьютер не реже одного раза в день, только это очищает виртуальную машину от мусора, оставленного от других приложений.

У вас никогда не было этой проблемы на 32-битной ОС, ее только сейчас с 64-разрядной ОС, что это происходит.

Answer 3

Short Story Ошибка моего 3035 была вызвана add.new в файл без первичного ключа.

Составление копии файла с назначенным первичным ключом и заменой файла без ключа, похоже, устранило проблему.

Long Story У меня возникла ошибка 3035 на Add.New на существующую бэкэнд-таблицу с> 81 000 записей. После поиска в Интернете идей и появления сухих я размышлял о возможных проблемах.

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

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

Использование нового файла, похоже, работает.