La operación no está permitida si el objeto está cerrado

gandalias_gandy · #1 (**permalink**) 12/07/2007, 01:59

Hola, al escribir este código ASP más abajo me da este problema, que hago mal
Tipo de error:

ADODB.Recordset (0x800A0E78)
La operación no está permitida si el objeto está cerrado.
/EntreFechas/entrefechas_sql.asp, línea 27

Tipo de explorador:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)

Página:
POST 48 bytes to /EntreFechas/entrefechas_sql.asp

Datos de POST:
F1=1%2F6%2F2007+00%3A00&F2=11%2F7%2F2007+10%3A00

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">

<meta http-equiv="Content-Language" content="es">

<title>Resultados B58 carrusel 1 n-situ</title>

</head>

<body>

<%@ Language=VBScript%>

<%

'conexion a gesprod

Dim oConn, rs, SQL

Dim ano1,ano2,mes1,mes2,dia1,dia2,hora1,hora2

Dim F1,F2

set F1 = request.Form ("F1")

set F2 = request.Form ("F2")

set dia1 = request.Form("ano1")

set dia2 = request.Form("ano2")

set mes1 = request.Form("mes1")

set mes2 = request.Form("mes2")

set dia1 = request.Form("dia1")

set dia2 = request.Form("dia2")

set hora1 = request.Form("hora1")

set hora2 = request.Form("hora2")

' Creamos los objetos sobre estas variables

set oConn = Server.CreateObject("ADODB.Connection")

oConn.Open "DSN=GESPROD;UID=SA;PWD=@-CE/2004-MOS"

SQL="select tempo from colate where tempo between '"&F2&"' and '"&F1&"';"

set rs = Server.CreateObject ("ADODB.Recordset")

oConn.Execute(SQL)

Response.Write("<TABLE>")

while not rs.EOF

Response.Write ("<TR>")

Response.Write ("<TD>"& rs.Fields("tempo" & "</TD>"))

Response.Write ("</TR>")

rs.movenext

Wend

Response.Write("</TABLE>")

rs.close

set rs=nothing

oConn.Close

%>

Myakire · #2 (**permalink**) 12/07/2007, 07:36

1) ¿Realmente existe el ODBC?
2) ¿El ODBC tiene autentificación SQL Server?
3) ¿Por qué no usas OleDb en lugar de ODBC?

Shiryu_Libra · #3 (**permalink**) 12/07/2007, 09:47

no se podra correjir esta parte:

Cita:

set rs = Server.CreateObject ("ADODB.Recordset")

oConn.Execute(SQL)

por:

Cita:

set rs = oConn.Execute(SQL)

Myakire · #4 (**permalink**) 12/07/2007, 13:56

mmmm, la verdad no llegué a esa parte del código dado que el mensaje de error dice que tronaba en la linea 27 y según conté era donde se abría la conexión

tammander · #5 (**permalink**) 13/07/2007, 07:46

¿Tu sabes lo mal que le sienta a Windows en general (y al SQL server en particular) este tipo de contraseñas?

@-CE/2004-MOS

A parte de ello, que es meramente informativo, el error que te devuelve es muy posible que se refiera a lo que dice Shiryu_Libra (

) Te recomiendo que uses la propiedad connectionString para asignar los datos de conexion:

set oConn = Server.CreateObject("ADODB.Connection")
oConn.connectionString = "DSN=GESPROD;UID=SA;PWD=@-CE/2004-MOS"
oConn.Open

Y luego lo dicho:

set rs = oconn.execute(SQL)

Tambien te recomiendo que chequees lo que viene por el request.form

Por ultimo, ¿Cual es la linea 27?

(para evitarle al pobre Myakire (

) tener que contar en un código sin numeración)

Un saludo
(buen fin de semana a todos)

daniel00 · #6 (**permalink**) 13/07/2007, 08:20

Que tal Gandy.

Yo también estoy de acuerdo con Shiryu_Libra.

Y es por eso cque cuando llega a la línea:

Código:

while not rs.EOF

el recordset (rs) no tiene nada, sólo esta instanciado.

Por otro lado, las asignaciones, se hacen de dos maneras:

1.- Asignación de variables simples: cadenas, numeros, fechas. Sólo se asigna, por ejemplo:

Código:

variable = request.Form("ano2")
variable = otravariable
variable = 123

2.- Cuando asignas objetos a otra 'variable', como son Connections, Recordsets, Fields y otros, regularmente son los que instancias con el método CreateObject del objeto Server, por ejemplo:

Código:

set oConn = Server.CreateObject("ADODB.Connection") 
set rs = Server.CreateObject ("ADODB.Recordset")
set rs = oConn.Execute(SQL)

Saludos!

u_goldman · #7 (**permalink**) 13/07/2007, 09:43

Cita:

Iniciado por tammander

¿Tu sabes lo mal que le sienta a Windows en general (y al SQL server en particular) este tipo de contraseñas?

@-CE/2004-MOS

Esto si es la primera vez que lo escucho leo...por qué?

Shiryu_Libra · #8 (**permalink**) 13/07/2007, 11:31

muy buena observacion, puedes ilustrarnos Tamm(

)

Myakire · #9 (**permalink**) 13/07/2007, 14:24

Supongo se refiere a esto:

Cita:

Password Policy

When it is running on Windows Server 2003 or later versions, SQL Server 2005 can use Windows password policy mechanisms.

SQL Server 2005 can apply the same complexity and expiration policies used in Windows Server 2003 to passwords used inside SQL Server. This functionality depends on the NetValidatePasswordPolicy API, which is only available in Windows Server 2003 and later versions.
Password ComplexityPassword Complexity

Password complexity policies are designed to deter brute force attacks by increasing the number of possible passwords. When password complexity policy is enforced, new passwords must meet the following guidelines:

* The password does not contain all or part of the account name of the user. Part of an account name is defined as three or more consecutive alphanumeric characters delimited on both ends by white space such as space, tab, and return, or any of the following characters: comma (,), period (.), hyphen (-), underscore (_), or number sign (#).
* The password is at least eight characters long.
* The password contains characters from three of the following four categories:
o Latin uppercase letters (A through Z)
o Latin lowercase letters (a through z)
o Base 10 digits (0 through 9)
o Non-alphanumeric characters such as: exclamation point (!), dollar sign ($), number sign (#), or percent (%).

Passwords can be up to 128 characters long. You should use passwords that are as long and complex as possible.

u_goldman · #10 (**permalink**) 13/07/2007, 14:30

Sigo sin entender...Se refiere a evitar al máximo los ataques por brute force, y de las recomendaciones anteriores le sentaría la de no caracteres alfanuméricos, pero para mi el comentario de tammander se me hace más como un asunto de performance.

Salú!!!!

CésarBalaguer · #11 (**permalink**) 13/07/2007, 14:55

Cita:

¿Tu sabes lo mal que le sienta a Windows en general (y al SQL server en particular) este tipo de contraseñas?

@-CE/2004-MOS

puedes definir "sentar mal al Windows"??
¿indigestion?
¿gases?
¿lagrimeos y estornudos?

bueno, luego de la broma viene el comentario...

La verdad nunca había leido sobre alguna restricción para password's salvo recomendaciones, como no poner tu nombre o cosas muy obvias, pero eso no es porque le siente mal al Windows sino mas bien por un tema de seguridad del usuario, he buscado en el Google y en la página de Microsoft y no he encontrado nada sobre restricciones por "sentar mal al windows o al sql server" sino mas bien recomendaciones por distinción de mayúsculas y minúsculas, caracteres alfanuméricos y no alfanuméricos, pero "sentar mal?" pues nop, no ubico aun la idea...

ojalá nos puedan explicar un poco más, siempre hay algo nuevo que aprender...

tammander · #12 (**permalink**) 14/07/2007, 09:12

Vaya paliza, chicos!!

Pues si, se refiere a lo que Myakire dice precisamente y a mi experiencia personal con sistemas Small Business de Windows Server 2003 y SQL Server 2005 enterprise. No soy administrador de sistemas sino un simple programador. Lo unico que se es que todo el calvario terminó cuando se le cambió una contraseña de ese tipo a un usuario Administrador en el SQL Server. Lo curioso fue que se le cambió en las directivas de serguridad del sistema ¿?

Ahora funciona todo perfectamente pero me fastidia no saber porqué

Ahora bien, cada cual es libre de administrar sus sistemas como crea conveniente.

Un saludo y buen fin de semana

u_goldman · #13 (**permalink**) 14/07/2007, 12:50

Cita:

Iniciado por tammander

Vaya paliza, chicos!!

Pues si, se refiere a lo que Myakire dice precisamente y a mi experiencia personal con sistemas Small Business de Windows Server 2003 y SQL Server 2005 enterprise. No soy administrador de sistemas sino un simple programador. Lo unico que se es que todo el calvario terminó cuando se le cambió una contraseña de ese tipo a un usuario Administrador en el SQL Server. Lo curioso fue que se le cambió en las directivas de serguridad del sistema ¿?

Ahora funciona todo perfectamente pero me fastidia no saber porqué

Ahora bien, cada cual es libre de administrar sus sistemas como crea conveniente.

Un saludo y buen fin de semana

Nah, es que por tu comentario yo al menos pensé se se debía a una cuestión de performance, ahora podré dormir tranquilio (más o menos)

Saludos

Myakire · #14 (**permalink**) 14/07/2007, 14:47

Cita:

Iniciado por u_goldman

Nah, es que por tu comentario yo al menos pensé se se debía a una cuestión de performance, ahora podré dormir tranquilio (más o menos)

Nunca te ha quitado el sueño nada técnico, y si fuera el caso solo le subes 1 o 2 por ciento el nivel de alcohol en la sangre y se arregla

AlZuwaga · #15 (**permalink**) 14/07/2007, 16:34

Cita:

Iniciado por Myakire

Nunca te ha quitado el sueño nada técnico...

A mi si!!!