Нужно ли закрывать объект Adodb.recordset, прежде чем устанавливать его на ноль? - PullRequest
10 голосов
/ 05 декабря 2011
Dim rs as ADODB.Recordset
set rs = ReturnARecordset 'assume ReturnARecordset does just that...

'do something with rs

rs.Close
set rs = Nothing

Нужно ли вызывать rs.Close, прежде чем устанавливать его в ноль?

Редактировать: у нас есть одно глобальное соединение, которое мы оставляем открытым на время работы приложения, и все объекты набора записей используют это жеподключение.Я вижу два ответа ниже, говорящих о необходимости закрытия наборов записей, чтобы гарантировать, что соединения не остаются открытыми.Для меня это звучит глупо, потому что соединения управляются объектами соединений, а не объектами записей, верно?Но, пожалуйста, дайте мне знать, если я что-то упустил здесь ...

Ответы [ 3 ]

5 голосов
/ 06 декабря 2011

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

Dim rs as ADODB.Recordset
Set rs = ReturnARecordset
...
MyControl.ObscureMethod rs
...
Set rs = Nothing

Предполагается, что последняя строказавершить экземпляр набора записей без явного вызова Close, если только MyControl не удерживает дополнительную ссылку и, таким образом, предотвращает нормальный разрыв.Вызов Close на rs убедит вас, что MyControl не может использовать его ссылку для чего-либо полезного, тем временем, сгорая в огне.

4 голосов
/ 05 декабря 2011

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

Это особенно очевидно, когда ADODB использует удаленное соединение, а не локальное.

1 голос
/ 06 декабря 2011

Вы можете столкнуться с проблемами пула ODBC или OLEDB, которые держат соединение открытым и связывают слот пула:

Распространенные причины проскальзывания соединения включают:

Соединение ADOи объекты Recordset на самом деле не закрыты.Если вы не закроете их явно, они не будут выпущены в пул.Это, вероятно, единственная наиболее частая причина ползучести соединения.

Созданный вами объект ADO (особенно объект Соединения) не был явно освобожден.Явное освобождение созданных вами объектов - это просто хорошая практика программирования.Если вы выделите память, отпустите ее.В зависимости от языка, который вы используете, выход переменной из области видимости может или не может привести к ее освобождению.

См. Пул в компонентах доступа к данным Microsoft

И если есть какая-либо вероятность того, что .Net Interop будет настороже: есть много предупреждений о проблемах, вызванных ленивым способом освобождения COM-объекта (или содержащегося объекта) в сборщике мусора .Net.

...