Форма заблокировала мой стол даже после docmd.close

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

Без кода трудно сказать, но если вы используете DAO, вам нужно очистить объекты кода. Это означает установку объектов базы данных в Nothing, а также закрытие и установку объектов набора записей в Nothing.

  Dim db As DAO.Database
  Dim rs As DAO.Recordset

  Set db = DBEngine.OpenDatabase("[path to database]")
  Set rs = db.OpenRecordset("[SELECT statement]")
  rs.Close
  Set rs = Nothing
  db.Execute("[DML or DDL statement]", dbFailOnError)
  db.Close
  Set db = Nothing

  Set db =CurrentDB
  Set rs = db.OpenRecordset("[SELECT statement]")
  rs.Close
  Set rs = Nothing
  Set db = Nothing  ' you don't close a db variable initialized with CurrentDB

Хотя предполагается, что VBA очищает эти объекты, когда они выходят за пределы области действия, он не надежен на 100 % (поскольку VBA использует подсчет ссылок, чтобы отслеживать, можно ли освободить объект, и не всегда знает, когда все ссылки удалены). был очищен).

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

РЕДАКТИРОВАТЬ, увидев, что вы используете DoCmd.RunSQL:

Использование DoCmd.RunSQL, вероятно, является причиной проблемы. Это, безусловно, то, что отнимает у вас программное управление вашими соединениями. Если вместо этого вы используете DAO, вы будете контролировать соединение, а также избежите настоящей ловушки DoCmd.RunSQL, заключающейся в том, что он не обрабатывает ошибки. Если оператор DML или DDL не может успешно завершиться полностью, все должно завершиться ошибкой. Например, если вы добавляете 100 записей, и 10 из них не соответствуют ключевым нарушениям, DoCmd.RunSQL прозрачно добавит 90 и НЕ СООБЩИТ О 10 ОШИБКАХ. То же самое с обновлениями и любым другим оператором DML/DDL. DoCmd.RunSQL «услужливо» автоматически завершает столько обновлений, сколько может, оставляя вас в неведении о том, что некоторые из них не удалось завершить.

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

Но в большинстве случаев это не так.

Как я сказал в своем комментарии выше, я использую функцию, которая предназначена для прозрачной замены DoCmd.RunSQL и использует оператор DAO Execute и обработку ошибок. Я публиковал его пару раз на SO (вот один), а вот версия, которую я использую в своем наиболее активном в настоящее время проекте разработки:

  Public Function SQLRun(strSQL As String, Optional db As Database, _
       Optional lngRecordsAffected As Long) As Long
  On Error GoTo errHandler
    Dim bolCleanup As Boolean

    If db Is Nothing Then
       Set db = CurrentDb
       bolCleanup = True
    End If
    'DBEngine.Workspaces(0).BeginTrans
    db.Execute strSQL, dbFailOnError
    lngRecordsAffected = db.RecordsAffected
    'DBEngine.Workspaces(0).CommitTrans

  exitRoutine:
    If bolCleanup Then
       Set db = Nothing
    End If
    SQLRun = lngRecordsAffected
    'Debug.Print strSQL
    Exit Function

  errHandler:
    MsgBox "There was an error executing your SQL string: " _
       & vbCrLf & vbCrLf & Err.Number & ": " & Err.Description, _
       vbExclamation, "Error in SQLRun()"
    Debug.Print "SQL Error: " & strSQL
    'DBEngine.Workspaces(0).Rollback
    Resume exitRoutine
  End Function

(транзакции закомментированы, потому что они вызывали проблемы, на устранение которых у меня не было времени)

Вы можете заменить эти строки своими:

  DoCmd.RunSQL "DELETE FROM tempExtract"
  DoCmd.RunSQL "INSERT INTO tempExtract SELECT (" _
    & DLookup("Value", "CONFIG_t", "Item = 'Xargs'" & ") FROM tempExtractID"

...с этим:

  SQLRun "DELETE FROM tempExtract"
  SQLRun "INSERT INTO tempExtract SELECT (" _
    & DLookup("Value", "CONFIG_t", "Item = 'Xargs'" & ") FROM tempExtractID"

Вы также можете сделать это:

  Debug.Print SQLRun("DELETE FROM tempExtract") & " records deleted."
  Debug.Print SQLRun("INSERT INTO tempExtract SELECT (" _
    & DLookup("Value", "CONFIG_t", "Item = 'Xargs'" _
    & ") FROM tempExtractID") & " records inserted."

Поскольку функция возвращает .RecordsAffected для каждого выполнения, вы можете печатать в Immediate Window, или вы можете присвоить возвращаемое значение переменной или передать ей существующую переменную и работать с этой переменной следующим образом:

  Dim lngRecordsAffected As Long
  ...
  Call SQLRun("DELETE FROM tempExtract", , lngRecordsAffected)
  Debug.Print lngRecordsAffected & " records deleted."
  Call SQLRun("INSERT INTO tempExtract SELECT (" _
    & DLookup("Value", "CONFIG_t", "Item = 'Xargs'" _
    & ") FROM tempExtractID", , lngRecordsAffected)
  Debug.Print lngRecordsAffected & " records inserted."

Дело в том, что если в операторе Execute есть ошибки, все это завершится ошибкой (и появится сообщение об ошибке - вы можете изменить его так, чтобы в случае ошибки он возвращал -1 или что-то в этом роде вместо того, чтобы выталкивать сообщение об ошибке). Сообщения).

Я использую эту функцию чаще всего, передавая предварительно кэшированную переменную базы данных, поэтому я не хочу потом ее очищать. Если вы используете другую базу данных, отличную от CurrentDB(), вы действительно хотите убедиться, что любая переменная базы данных, указывающая на ваш внешний db, закрыта и установлена ​​​​в Nothing. Без этого на объектах базы данных верхнего уровня сохраняются блокировки, а файл LDB остается открытым и активным.