Нужно ли закрывать объект 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 позволяет это делать в некоторых случаях).