Si ana, es sencillo, el uso de <%%> es para el código que se ejecutará en el servidor, esto es que se pre-procesará para enviar después HTML al cliente, o sea, cualquier lenguaje de programación que interprete ASP, que por default será VB, aunque también lo puedes hacer con javascript server side...de tal suerte que puedes incluso enviar strings como HTML dentro de scripts como lo estabas haciendo:
Esto es HTML puro:
<center><font face arial size=2>Hola Mundo</font></center>
Esto es HTML envíado como string.
<%
Response.Write("<center><font face arial size=2>Hola Mundo</font></center>")
%>
Al caso el efecto es lo mismo, aunque dicen por allí que es un poco más rápido de la segunda forma, quien sabe cuantas milésimas de segundo
Ahora, cuando usarlo y cuando no? pues creo que eso es a gusto del programador, para mi me resulta más cómodo intercalar HTML puro y dejar entre <%%> sólo la parte lógica.
El problema que tenías en realidad no era ese...ve un poco más a detalle el código:
código original:
Cita: <%
set oConn = Server.CreateObject("ADODB.Connection")
oConn.Open("DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" & Server.MapPath("\bd1.mdb"))
set oStr = "SELECT * FROM centro"
set oRs = oConn.Execute(strSQL)
i=1
Do While Not oRS.Eof
El código que funcionó
Cita: <%
set oConn = Server.CreateObject("ADODB.Connection")
oConn.Open("DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" & Server.MapPath("\bd1.mdb"))
StrSQL = "SELECT * FROM centro"
set oRs = Server.CreateObject("ADODB.Recordset")
oRs.Open strSQL, oConn, 3, 3
i=1
%>
Ahora si te fijas, primero estás creando como objeto la sentencia SQL que tu le llamaste oStr, después creas un recordset, mediante el método execute de la conexión activa, pero le estás pasando una variablle strSQL, dónde está en realidad la sentencia?? por alguna razón no te enviaba error y solo te bloqueaba el script...
en el código que arreglamos, hicimos una variable strSQL con la sentencia SQL, después creamos un recordset y lo abrimos(oRs), sin invocar al método execute de la conexión, sino pasándole la sentencia, la conexión activa y para contestar a tu segunda pregunta, el cursor con el cuál vamos a abrir el recordset y claro, el tipo de cerrojo con la que se abrirá ese recordset.
Qué es un cursor?
El recordset es un objeto por si mismo, el cual tiene propiedades, métodos y eventos.
Un cursor te permite moverte a través del objeto recordset, hay diferentes tipos de cursores, en este caso el 3, te permite desplazarte libremente por el recordset, esto es para adelante, para atrás, al último y al primer registro, pero hay ocasiones en las cuales quizás no lo requieres o por alguna razón solo quieres que se mueva hacia adelante y que no pueda retroceder, pues el manejar estos cursores servirá para este fin.
Qué es un cerrojo?
Es un permiso temporal con el cuál tu puedes trabajar los campos de tu DB, y también hay varios, dependiendo de la naturaleza de tu aplicación y de la seguridad que quieras que tengan tus datos, puedes implementar el que mas se ajuste a tus necesidades, imagínate que tienes una DB con una alta concurrencia, pero que no quieres que todo mundo tenga acceso al mismo tiempo a un registro para modificarlo, entonces emplearías un cerrojo de tipo pesimista, en el cual bloqueará temporalmente dicho registro para que no pueda ser alterado, en tanto no se desocupe.
Espero que te quede un poco mas claro.
Salu2,
menu con elementos de una consulta sql 
Este tema le ha gustado a 1 personas