Visual Basic, VB .NET, ASP, Active X, Access, SQL Server

ASP: não armazene conexões ao banco de dados nos objetos Application ou Session

Armazenar conexões ADO costuma ser uma estratégia ruim. Se um objeto Connection for armazenado no objeto Application e usado por todas as páginas, haverá uma disputa entre as páginas pelo uso desta conexão. Se o objeto Connection for armazenado num objeto ASP Session, então uma conexão ao banco de dados será criada para cada novo usuário que se conecte ao site. Isto remove o benefício do pooling  de conexões e adiciona uma carga extra tanto para o servidor Web quanto para o banco de dados. Ao invés de armazenar conexões ao banco de dados, crie e destrua objetos ADO em cada página ASP que use ADO. Isto é eficiente, porque o IIS habilita automaticamente o pooling de conexões tanto ODBC como OLEDB.  Isto garante que a criação e destruição de conexões em cada página seja eficiente. Você, no entanto, deve lembrar-se de fechar e destruir explicitamente todas as conexões que não esteja mais usando. Caso você não use o método Close do objeto Connection e atribua Nothing à variável usada para manter uma referência ao objeto, o IIS não acolherá a sua conexão no pooling para ativá-la na próxima requisição por uma conexão.

Uma vez que recordsets conectados armazenam referência a uma conexão ao banco de dados, conclui-se que você não deve armazenar recordsets conectados nos objetos Application ou Session. Contudo, recordsets desconectados podem ser eficientemente  armazenados, porque não mantêm referência a nenhuma conexão. Para desconectar um recordset faça como a seguir:

Set rs = Server.CreateObject(?ADODB.RecordSet?)

rs.CursorLocation = adUseClient ' passo 1

' Preencha o recordset com dados

rs.Open strConsulta, strProvedor

' Agora desconecte o recordset do provedor de dados e da fonte de dados

rs.ActiveConnection = Nothing ' passo 2