Damos espacio a sus ideas


intranetconozcanoscontactenosorden de servicio


hospedaje
diseño web
productos y servicios
comercio electronico

© RSID

Prácticas para código ASP/ADO

Propósito
El propósito de este documento es para describir un conjunto de practicas de código ASP/ADO que lo ayudarán a crear aplicaciones web que funcionen mejor en un ambiente compartido de hosting.

Siguiendo estas reglas hará posible que su sitio sea más rápido y ayudará a minimizar la ocurrencia de los errores RPC.

Causas de los errores RPC
Primero es importante comprender porqué ocurren errores RPC. No existe una respuesta definitiva, sin embargo, los hechos sugieren que los errores frecuentes de RPC pueden ser causados por:

  • No cerrar todo los objetos creados en un script.
  • Uso de un archivo de base de datos (Access en particular).
  • Usar los objetos Application o Session para guardar otros objetos.

No cerrar todos los objetos creados en un script
Mientras que el ASP debería, supuestamente, cerrar todos los objetos cuando termina el script, el proceso que ejecuta esta acción no es infalible. En este caso, es mejor prevenir que curar. Conclusión: cerrar todos los objetos creados en un script.

Uso de un archivo de base de datos (Access en particular)
Las bases de datos, en especial Access, no son muy eficientes para usarlas en un sitio de gran producción. Incluso si son chicas o poco usadas, los problemas pueden aparecer. Nuestra recomendación es que nuestros clientes usen bases de datos SQL Server, y que se conecten usando el driver OLE-DB en vez de ODBC. Además de ser más eficiente, el driver SQL Server OLE-DB es mucho más rápido que el ODBC.

Usar los objetos Application o Session para guardar otros objetos
Bandera roja en este punto. Guardar objetos en Session o Application Objects introduce varios problemas como afinidad en las tareas, pedido de serialización y alto uso de memoria. Nuestra recomendación es que estos objetos nunca se usen para guardar otros objetos, particularmente objetos ADO.

Escribiendo mejor código

Uso de Objetos
Este punto es simple: No crear objetos hasta que sean necesarios, cerrar los objetos una vez terminados con ellos. Y siempre utilizar explícitamente Server.CreateObject para crear objetos.

Header & Footer Scripts
Es una buena idea usar scripts Header & Footer estandarizados para contener funciones comúnmente usadas en su script y para obtener información necesaria por todos sus scripts. En un sitio que utilice bases de datos, migrar el código para crear/destruir objetos ADO y establecer las conexiones de la base de datos como subrutina puede ser muy beneficioso porque esto ayuda a eliminar una gran cantidad de código redundante y lo fuerza a manejarse con la base de datos de una manera más consistente en todos sus scripts.

Application Object
La información guardada en el objeto Application es utilizable por todos los scripts en su aplicación sin importar el usuario o sesión. Usar este objeto para guardar información global de la configuración (como ser la conexión de la base de datos) es, definitivamente, una buna idea. Es nuestra recomendación que el objeto Application nunca se use para guardar otros objetos, siempre hay una mejor solución.

Session Object
El objeto Session tendría que ser utilizado para guardar información que es específica al actual usuario o sesión. Al usar este objeto para información persistente a lo largo de todos los scripts, tenga cuidado de asegurarse que cuando un usuario aprieta el botón Back del navegador, este no cause un error. Es nuestra recomendación que el objeto Session nunca se use para guardar otros objetos.

Las versiones anteriores del Microsoft Visual InterDev 6.0 son un mal ejemplo de utilización del objeto Session ya que guardan información estática sobre la conección a la base de datos. Con la versión 6.0 esto se arregló y ahora se guarda en el objeto Aplicación..

Visual InterDev
El Visual InterDev es una excelente herramienta de desarrollo web. Como editor y herramienta de trabajo, es muy buena, pero no es un reemplazo al conocimiento en programación. El código creado por el Visual InterDev, en especial las versiones anteriores a la 6.0, son muy complicados, susceptibles a errores y muy difícil de depurar. Generar el código de la forma antigua, manualmente, resultará en un código más fácil de entender, verificar y mantener por uno mismo.

Bases de Datos
Las tres reglas para bases de datos en la web son: SQL Server, SQL Server y SQL Server. Otras bases de datos como Access o FoxPro tienen una pobre performance y problemas de escalabilidad.

El SQL Server es rápido, soporta web sites muy activos y ofrece eficiencia. Además Ud. ahorrará tiempo ya que con Enterprise Manager o Visual InterDev podrá manipular su base de datos directamente en Internet en vez de tener que bajarla, modificarla y luego subirla nuevamente.

Si va a usar bases de datos debe considerar seriamente el usar el SQL Server.

ADO vs. OLE-DB vs. ODBC
ODBC es el estándar de Microsoft para acceder las bases de datos. Fue el primer estándar. OLE-DB es una actualización creada para las aplicaciones en 32-bits. Fue creada para ser más rápida y eficiente y estable que ODBC. ODBC y OLE-DB son interfaces de bajo nivel; una aplicación típica o un desarrollador web no usaría estos APIs directamente.

Para hacer el OLE-DB más fácil para los desarrolladores utilizando lenguajes de alto nivel como VBScript, el ADO fue creado. ADO provee un mecanismo simplificado para acceder a las bases de datos OLE-DB. Para permitir que las aplicaciones OLE-DB (y también ADO) trabajen con bases de datos más viejas, que no han sido actualizadas al estándar OLE-DB, como Access, Microsoft también creó el "OLE-DB Provider for ODBC Databases".

Si usted está usando Access, FoxPro, o SQL Server vía System DNS, su conexión de base de datos va a través del "OLE-DB Provider for ODBC Databases". Acceder a una base de datos involucra ir a través de las cuatro capas API: ADO -> OLE-DB -> OLE-DB Provider for ODBC Databases -> ODBC Driver.

Al cambiarse al SQL Server y especificando su OLE-DB driver, el OLE-DB Provider for ODBC Databases puede ser eliminada del proceso. Ahora sus Queries solo irán en tres capas API: ADO -> OLE-DB -> OLE-DB Driver.

Usando OLE-DB para conectar a su SQL Server es tan simple como cambiar su string de conexión:

Provider=SQLOLEDB
User ID=USERID
Password="PASSWORD"
Initial Catalog= DBNAME

Reemplace las palabras en bold con la información específica de su cuenta.

.

Ultima modificación: 03/11/2000


¿VERIFIQUE SI SU DOMINIO ESTA DISPONIBLE?
www.