Нужно ли закрывать объект Adodb.recordset до того, как он ничего не изменит?
Dim rs as ADODB.Recordset
set rs = ReturnARecordset 'assume ReturnARecordset does just that...
'do something with rs
rs.Close
set rs = Nothing
Нужно ли вызывать rs.Close перед тем, как установить его в нуль?
Изменить: у нас есть одно глобальное соединение, которое мы сохраняем открытым в течение всего срока действия приложения, и все объекты набора записей используют это же соединение. Я вижу два ответа ниже, говоря о необходимости закрытия наборов записей, чтобы убедиться, что соединения не остаются открытыми. Для меня это звучит как много глупых разговоров, потому что соединения контролируются объектами соединения, а не объектами записей? Но, пожалуйста, дайте мне знать, если я что-то упустил...
Ответы
Ответ 1
Единственная причина, вызывающая явное выражение Close
, заключается в том, что вы не уверены, ссылается ли набор записей из другого места в вашем проекте, как правило, результат некоторого неаккуратного кодирования.
Dim rs as ADODB.Recordset
Set rs = ReturnARecordset
...
MyControl.ObscureMethod rs
...
Set rs = Nothing
Последняя строка должна завершать экземпляр набора записей без явного вызова Close
, если MyControl
не содержит дополнительную ссылку и, таким образом, предотвращает нормальный срыв. Вызов Close
on rs
гарантирует, что MyControl
не сможет использовать свою ссылку для чего-нибудь полезного, в то же время разбившегося в огне.
Ответ 2
Да, это больше, чем просто принудительная сборка мусора, она также сообщает серверу, что соединение прекращается, это позволяет избежать наличия нескольких открытых сиротских подключений (они, в конечном счете, тайм-аут сами по себе), но всегда лучше всего их закрыть вне.
Это особенно заметно, когда ADODB использует удаленное соединение, а не локальное.
Ответ 3
Вы можете столкнуться с проблемами ODBC или OLEDB Pooling, которые открывают соединение и связывают слот для пула:
Общие причины ползучести соединения включают:
Объекты соединения ADO и Recordset фактически не закрыты. Если вы явно не закрываете их, они не будут выпущены в пул. Это, вероятно, самая частая причина ползучести соединения.
Объект ADO, который вы создали (особенно объект Connection), не был явно выпущен. Явное освобождение объектов, которые вы создаете, - это просто хорошая практика программирования. Если вы выделите память, отпустите ее. В зависимости от языка, который вы используете, разрешение переменной выходит за пределы области видимости, может или не может привести к ее освобождению.
См. Объединение компонентов Microsoft Data Access
И если есть какие-то шансы .Net Interop быть осторожным: существует множество предупреждений о проблемах, вызванных ленивым способом выпуска COM-объекта (или содержащегося объекта) в коллекции мусора .Net.
Ответ 4
Ваши ответы на сегодняшний день по этому вопросу игнорируют несколько важных факторов:
1) Набор записей открыт синхронно или асинхронно? (ВАЖНОЕ различие)
2) ОТКРЫТЫЕ, СОЕДИНЕННЫЕ наборы записей (с или без каких-либо возвращаемых данных) потребляют накладные расходы ДРУГИЕ, а не просто выделенные буферы памяти - возможны коммуникации по соединению (особенно, если есть асинхронные операции во время работы), даже, возможно, после того, как мы думаем, что мы закончили с набор записей (предположим, что происходит событие на стороне сервера, которое влияет на RS... кто-то другой на другом соединении усекает любую из таблиц, влияющих на ваш набор записей... текущая запись просто стала недействительной/удаленной и т.д.,. или основное соединение). Здесь есть несколько путей для неприятностей. Если только вы не в тонусе с какой-то дисциплиной кодирования в этом, вы можете получить те же самые пальцы, что и вам! (ОСОБЕННО, если мы обсуждаем асинхронные операции!)
3) Каково ваше НАСТОЯЩЕЕ оправдание за то, что вы не делаете .close (или в этом отношении "set x = Nothing" в вашем коде)?... слишком ленив для этого? Вот подсказка: ленивые программисты часто отстойные программисты, которые оставляют за собой глючный код. Гордитесь своей работой и делайте ее правильно (ну, в той мере, в какой Microsoft позволяет это делать в некоторых случаях).