Probando y Optimizando Procedimientos Almacenados

Probar y optimizar un procedimiento almacenado es una tarea complicada, más aún cuando el procedimiento no lo hemos escrito nosotros.

Un procedimiento almacenado podría ejecutarse muy lentamente, afectando a la aplicación demandante. Las causas son muchas: hardware, memoria, sistema operativo, red, etc.

Podemos empezar realizando una estadística de la ejecución del procedimiento almacenado, detallando ciclos de CPU utilizados, lecturas, escrituras, tiempo de duración, observaciones, etc.

Vamos llevando esos datos mientras realizamos cambios, de modo que podamos tener un control, que cambio afecta o mejora el desempeño del procedimiento.

Antes de hacer las mediciones del desempeño de los procedimientos hay que ejecutar las siguientes comandos en el Analizador de Consultas:


DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE

Esto "limpia" los buffers y el cache de Sql Server, de modo que permite un análisis más exacto del rendimiento del procedimiento. Ya el resto depende de quien analice el procedimiento, aunque podemos revisar los siguientes puntos:

  • Evitar crear tablas temporales, sentencias sql dinamicas y joins.
  • Cuidar que la salida del procedimiento almacenado sea la misma que antes de la optimización.
  • Debemos de ver cual es la ejecución de cada sentencia DML.
  • Evitar los Table Scan.
  • Que las sentencias SQL sean escritas en formato ANSI, no ayuda mucho al desempeño, pero si a entenderlas.
Como recomendación, siempre hay que pensar de esta forma: un procedimiento almacenado se puede optimizar para ejecutarse en menos tiempo o para ser de menor tamaño, y no se puede obtener ambos siempre, en el mejor de los casos, hay que decidir que aspecto queremos mejorar.

Como se ve no hay reglas exactas para optimizar procedimientos almacenados, pero si ciertas reglas generales.

Comprobar si un email es correcto

¿como comprobar que la dirección de correo electrónico o e-mail ha sido digitado correctamente?

Si es real o no el e-mail, es imposible saberlo, pero por lo menos podemos descubrir si el usuario ha tecleado algo similar a una dirección de correo, si por lo menos tiene dentro el símbolo de la arroba ('@').

Declare @DirecionDeCorreo varchar(100)
SET @DirecionDeCorreo = 'test@xx.com'
If NOT (@DirecionDeCorreo LIKE '[^.@]%[^.@]@[^.@]%[^.@].[^.@]%[^.@]' OR @UserEmail LIKE '%@%@%')
Begin
Print ‘error’
End

Podemos adaptarlo, para colocarlo en una función o procedmiento almacenado.

Script para eliminar registros o filas duplicadas

Generalmente, cuando importamos datos a una tabla podemos llegar a tener algunos registros duplicados. El problema es como deshacernos de ellos, sin revisar uno por uno los registros o filas, que en algunos casos pueden pasar de las decenas de miles.

Con el siguiente script puede ser más sencillo (hay que adaptarlo segun la tabla):

/*******************************************************************/
/* Script para eliminar registros duplicados de tabla Empleados */
Declare @id int,
@name varchar (50),
@cnt int,
@salary numeric

Declare getallrecords cursor local static For
Select count (1), id, name, salary
from employee (nolock)
group by id, name,salary having count(1)>1

Open getallrecords

Fetch next from getallrecords into @cnt,@id,@name,@salary
--cursor para chequear los otros registros
While @@fetch_status=0
Begin
Set @cnt= @cnt-1
Set rowcount @cnt

-- eliminar los registros duplicados. Observa que todos los campos son mencionados -- en la condicion
Delete from employee where id=@id and name=@name
and salary=@salary

Set rowcount 0

Fetch next from getallrecords into @cnt,@id,@name,@salary
End

Close getallrecords
Deallocate getallrecords

*******************************************************************

Antes que todo hay que realizar una copia de seguridad, para darnos cuenta como trabaja el script. Lo recomiendo, y antes de ejecutarlo contra datos importantes, pruebalo con una tabla de prueba, no me responsabilizo por pérdida de datos importantes.

Limpiar conexiones no utilizadas (Script)

Este script ActiveX corre en el diseñador de DTS y limpiará las conexiones no utilizadas.

Esto permite renombrar las conexión, seleccionando Nueva Conexión y tipeando un nuevo nombre.

También permite copiar y pegar conexiones para renombrarlas.

Luego puedes limpiar las conexiones abandonadas cuando el desarrollo este completo.




'**********************************************************************
'* Script ActiveX
'**********************************************************************
'* Limpiar conexiones no utilizadas
'**********************************************************************
'* ----------------------------------------
'* Descripcion:
'* Este script realiza un ciclo a traves de cada conexion en un paquete y la libera '* si no esta siendo utilizada.
'* ----------------------------------------
'* Uso:
'* 1. Agregar una tarea a un paquete DTS.
'* 2. Deshabilita esta tarea propiedades del flujo de trabajo, de modo que no se
'* ejecute con el paquete.
'* 3. Copia este script en la tarea ActiveX.
'* 5. Realiza una copia de seguridad del paquete. (No olvidar este paso)
'* 6. Guarda el paquete. (No olvidar este paso)
'* 7. Ejecutar el script ActiveX en el diseñador DTS, guardar, y cerrar el paquete.
'*-------------------------------------------------------------------------------------
'* Nota:
'* - Este script no debe ser ejecutado sin supervisión.
'* - No editar el script en Propiedades del Tarea ActiveX.
'* - Editar como un archivo .vbs en, y depura scripts el el Microsoft Script Editor.
'-------------------------------------------------------------------------------------
Function Main()
On Error Resume Next
Stop
Dim loPackage
Dim loConnections
Dim loConnection
Dim loTasks
Dim loTask
Dim loProperties
Dim loProperty
Dim lbConnectionUsed
Set loPackage = DTSGlobalVariables.Parent
Set loConnections = loPackage.Connections
Set loTasks = loPackage.Tasks
' Reiniciar despues de cambiar de coleccion
Do
' Loop Through Connections
For Each loConnection In loConnections
lbConnectionUsed = False
' Loop Through Tasks
For Each loTask in loTasks
Set loProperties = loTask.Properties
' Loop Through Properties
For Each loProperty in loProperties
If Instr(loProperty.Name, "ConnectionID") Then
If loProperty = loConnection.ID Then
lbConnectionUsed = True
Exit For
End If
End If
Next
If lbConnectionUsed = True Then
Exit For
End If
Next
If lbConnectionUsed = False Then
loConnections.Remove loConnection.Name
Exit For
End if
Next
If lbConnectionUsed = True Then
Exit Do
End If
Loop
Set loPackage = Nothing
Set loConnections = Nothing
Set loConnection = Nothing
Set loTasks = Nothing
Set loTask = Nothing
Main = DTSTaskExecResult_Success
End Function

Consulta sobre Pocket PC

He recibido un correo de Sergio Claver, consultando sobre desarrollo para Pocket PC, no soy un experto pero trataré de responder según lo que sé:

siempre he querido hacer programas simples para pocket pc,
me parecio siempre algo confuso pues leia que varias personas hablaban de net, visual studio, asp, xml, visual basic, embedded, etc.

Luego averiguando ultimo me entere que microsoft habia tratado de uniformizar todo lanzando kits para desarrolladores.

Bueno mi pregunta es esta,
Que tan dificil es crear un programa "bonito" y "simple" tipo los de SPB por ejemplo para calcular areas, que como sabes es tan solo una multiplicacion, suma y resta.

y otra

si tengo un traductor de palabras en un formato ejecutable exe para PC que segun el autor es libre de ser modificado, como hago para pasar ese programa de 32bits a pocket pc o mobile ?



Respuesta:

Hacer un programa para Pocket PC es muy simple, ahora que contamos con Visual Studio 2005/2008. Te sorprenderá saber que es casi programar igual que para Windows, en Visual Studio te dan plantillas y según el lenguaje que uses (yo utilizo Visual Basic) solo algunos comandos no son posibles de usar en Pocket PC. Microsoft proporciona un Mobile SDK para el desarrollo de estas aplicaciones. En esta entrada publiqué algunos enlaces que te pueden ayudar. Luego tienes que saber como probar tu aplicación, sin tener el dispositivo.

Ahora, respecto al programa ejecutable para PC, si tienes el código fuente, es dificil pero no imposible "traducirlo" al Pocket PC. Lo importante es tener el código fuente. Ahora sólo habría que ver como te comenté líneas arriba si utiliza sentencias o comandos que no se pueden utilizar en Pocket PC.

Espero que haya entre los lectores alguien que conozca más del tema y nos oriente un poco más.

Entradas Relacionadas:

Visual Basic pronto en Linux

Visual Basic es el lenguaje de programación más extendido por el mundo, tal vez por su facilidad de aprendizaje. Sin embargo su origen lo limita a una plataforma. Sólo se pueden programar en Visual Basic aplicaciones Windows.

Pero, en el futuro se va a tener la posibilidad de portar aplicaciones Windows hechas en Visual Basic hacia su principal competidor: Linux. El responsable de esta novedad, que aumentará el campo de distribución de aplicaciones desarrolladas en Visual Basic, es el Proyecto Mono.

Mono es el nombre de un proyecto de código abierto iniciado por Ximian y actualmente impulsado por Novell (tras su adquisición de Ximian) para crear un grupo de herramientas libres, basadas en GNU/Linux y compatibles con .NET según lo especificado por el ECMA.

Los integrantes del Proyecto Mono anunciaron el desarrollo de un compilador para Visual Basic que permitirá ejecutar sus aplicaciones independiente de la plataforma (tienen que soportar Mono) y sin modificaciones de código.

¿Será este uno de los resultados de la colaboración entre Microsoft y Novell para aumentar la interoperabilidad entre los sistemas operativos Windows y GNU/Linux? Lo que parece seguro es que esta característica fomentará la migración de mucho software que antes sólo se podía ejecutar bajo Windows a las plataformas del pingüino.

Fuente:
SeguiLaFlecha

Microsoft Live Labs Volta: Convierte Aplicaciones de Escritorio a Aplicaciones Web

Volta es un conjunto de herramientas que permite construir aplicaciones web multicapa aplicando técnicas y patrones familiares. Primero hay que diseñar y construir una aplicación como una aplicación cliente .NET, luego asignar las porciones de la aplicación para ejecutar sobre el servidor y los que se ejecuten en la capa cliente. El compilador crear código JavaScript para la capa cliente, servicios web para la capa servidor, y comunicación, serialización, sincronización, y otro código necesario para unir a las capas.

Los desarrolladores pueden desarrollar aplicaciones hacia cualquier explorador de internet o CLR y Volta será el que maneja las complejidades de dividir las capas por ellos.

Enlace:
Volta

Buenas Practicas en Diseño de Base Datos

Introducción



Un DBMS no facilita diseñar correctamente una base de datos. Muchas veces debemos haber pasado por lo mismo. Nos piden diseñar la base de datos para un sistema, entonces procedemos a crear tablas y nombrarlas del modo que se nos ocurra o entendamos, pero cuando empezamos a desarrollar reportes para el sistema, puede ser dificultoso.

¿Haces eso? Pues ¡¡para!!. Recuerda que es un trabajo, y es un reflejo de tí como empleado y habla también acerca de tí como persona. Claro que a veces toma tiempo extra para entender el modelo de datos, pero ese tiempo extra pagará dividendos cuando necesites extraer datos o permitir el acceso a ellos de los usuarios.

Veamos cual sería una buena forma de llamar a nuestras bases de datos, tablas, columnas, procedimientos almacenados e incluso vistas.

Convenciones para tablas o vistas


Tipo de Tabla o VistaSufijo para TablaDescripción
Tabla de HistóricoshistEsta tabla almacena información histórica. Típicamente es una relación de una a varios.
Tabla de Referencia
refEste tipo de tabla almacena nombres y descripciones. Ej. 1=Perros.
SnapshotcurrentAlmacena información actualizada, típicamente se utiliza con tablas históricas para almacenar el último registro para una clave externa.
Primera Instanciaorig
Almacena la primera instancia de una clave externa, es lo opuesto al Snapshot, pero contiene los mismo datos si es que sólo hay un registro de la clave externa.


Casos especiales de Vistas



Muchos DBA no dejan que los usuarios accedan directamente a las tablas, para eso utilizan vistas para las consultas contra las tablas. Es una buena práctica siempre que no haya demasiados joins.

Para una vista, podemos nombrarla con una letra "v" o "vw" al comienzo del nombre, que ayuda cuando cuando se lista las vistas fuera del Administrador Corporativo tal como Microsoft Access. Gracias a ese prefijo el usuario puede distinguir si es una vista o una tabla, y cual es el tipo de información almacenada en la tabla y que tipo de tabla es.

Notarán que no se indica utilizar un prefijo para una tabla. Esto es para establecer que siempre que un objeto no tenga prefijo es una tabla, y cuando tenga prefijo es una vista o procedimiento almacenado.

Convenciones para nombrar columnas



A veces uno tiene reglas para nombrar tablas, vistas o procedimientos almacenados. Sin embargo cuando se trata de columnas no lo tenemos. Una regla que puede ayudarnos mucho y ahorrarnos tiempo es llamar a la columna A de la tabla 1, llamarla también A en la tabla 2. Un simple movimiento que puede salvarnos de muchos problemas.





















































Tipo de ColumnaSufijo de ColumnaDescripción
Nombre del elementonameUsada para describir el nombre de una clave principal
Descripción del elementodescUsada para describir el nombre con más detalle
Fecha de los datosentry_dateUsada para marcar con fecha una fila
Usuario que ingresó datosingresado_porUsada para registrar que usuario o aplicación introdujo los datos
Fecha de actualización de los datosupdate_dateMuestra la fecha en que se actualizaron los datos
Usuario que actualizó los datosmodificado_porUtilizada para almacenar el usuario que modificó los datos
Clave primaria númerica<<>>_idUtilizada describir la clave primaria cuando la clave es un valor númerico


Procedimientos Almacenados



Una convenció que puede utilizarse es 'usr_<>, de modo que cuando se depure la aplicación se sabe que un objeto con 'usr_' es un procedimiento almacenado. Hay que incluir dentro del nombre algo que indique que es lo que hace el procedimiento almacenado. Por ejemplo si un procedimiento almacenado actualiza la categoría de un producto, se le puede llamar 'usr_ActualizarCategoria'.

Bases de Datos



Ultimamente el uso de una convención para llama a la base de datos. Similar a la convención de nombres para procedimientos almacenados, como usar el prefijo 'dev' y 'prod' para distinguir entre una base de datos de desarrollo y una de producción.

Conclusión



Las convenciones de nombres que menciono no son dificiles de seguir. Usualmente, bueno, casi siempre somos presionados en el tiempo para diseñar una base de datos. No hay que sentirse mal por eso, no es nuestra culpa. Pero hay que tomarnos el tiempo para establecer y seguir nuestras convenciones de nombres. Tres meses después, cuando revisemos el código nos agradeceremos a nosotros mismos por eso. La clave de todo esto es ser consistente. Si somos consistentes, modificar el código será mucho más fácil.

¿Ustedes tienen alguna convención de nombres?

Mejores Practicas en Desarrollo para Sql Server

Si, hay prácticas buenas y hay prácticas malas en Sql Server.

¿Que pasa si no se siguen las buenas prácticas?



Pasa, que vas a empezar a decir y escuchar cosas como estas:

- ¡Qué raro! En mi casa funcionaba
- El usuario sa debe tener una clave determinada
- ¿Añadir ese dato en la tabla clientes? No creo que se pueda...

Lista de buenas prácticas:



- Gestión del código fuente: no sólo producción debe tener lo último, debe haber un control de versiones.
- Gestión del esquema: importación del esquema, ingeniería inversa, esquemas en SQL, organización del esquema (por tipo de objeto, por esquema), tareas pre y post deployment, refactorización, más de un fichero por objeto.
- Comparaciones de objetos: de esquemas, diferencias entre versiones, generación de scripts de diferencias, actualización, creación y borrado de objetos.
- Pruebas en bases de datos: pruebas de carga (con datos), datos de producción o datos inventados, probar integridad referencial.
- Pruebas en las bases de datos: pruebas unitarias (script anterior, prueba, script posterior), pre y post condiciones.
- Generación e implementación: consolidación de varios scripts.
- Otras buenas prácticas: vistas y vistas indexadas, procedimientos almacenados, desencadenadores (triggers) DDL y DML, services brokes en aplicaciones.

SQL Server 2008 Database Backup Compression

SQL Server 2008 Database Backup Compression una nueva herramienta desarrollada por Microsoft, especialmente diseñada para los administradores y profesionales TIC que hacen copias de seguridad o backups y recuperación de bases de datos en SQL Server 2008.

Microsoft asegura que aunque la utilización del CPU aumenta debido a la tarea adicional de compresión, el tiempo de hacer un backup de la base de datos se reduce considerablemente.

Esta herramienta funciona en la versión 2008 de Sql Server, para versiones anteriores pueden utilizar una alternativa de backups con Winrar.

Enlaces:
Vnunet.es
Microsoft Technet

¿Hay diferencia entre las distintas ediciones de Sql Server 2000?

El desarrollo contra un servidor Sql Server idealmente debería realizarse sobre un servidor o una computadora con un sistema operativo para servidores, pero realmente los desarrolladores sólo contamos con sistemas operativos para usuarios. Felizmente Microsoft ofrece ediciones diferentes de Sql Server, en la versión 2000 ofrece Sql Server Personal Edition que tiene algunas diferencias en el rendimiento respecto de la versión Enterprise. Hay otras versiones, a continuación una lista con una corta explicación de las diferentes versiones:

SQL Server 2000 Enterprise Edition
Es la edición más completa. Incluye algunas posibilidades no disponibles en otras ediciones, como vistas indexadas o configuraciones extendidas de hardware.

SQL Server 2000 Standard Edition
Este el el motor de bases de datos convencional para instalar en cualquier servidor, salvo que se necesiten vistas indexadas y soporte de capacidades de hardware extendidas (más de 2 Gb de RAM, más de 4 CPUs, y clusters, por ejemplo) ...

SQL Server 2000 Personal Edition
Versión parecida a la Standard, pero limitada legalmente a ser utilizada para uso personal, no como servidor de datos en red. Sólo soporta 2 CPU. En cuanto se envían más de cinco consultas simultáneamente, el sistema degrada a propósito la velocidad.

SQL Server 2000 Developer Edition
Idéntica a la Enterprise Edition, pero limitada a 8 licencias de desarrollo, no pudiéndose utilizar legalmente en producción.

SQL Server 2000 Desktop Engine (MSDE)
Versión especial para ser utilizada en aplicaciones específicas. Es solamente el motor de la base de datos, sin utilidades de administración, y limitada a 2 Gb por base de datos. La velocidad de proceso baja, a propósito, en cuanto se tienen que procesar más de ocho peticiones simultáneas. Esta es la única edición que no trae ni el Query Analyzer, ni el Enterprise Manager ni ninguna de las herramientas cliente para su administración.

Conclusión


Como se puede leer, no hay diferencias en características, sólo en rendimiento y procesamiento, ya que las ediciones fueron creadas para distintos escenarios.

Conectarse a Servidor Sql Server a través de Internet

Hace mucho tiempo que no posteo en este blog, es en parte falta de tiempo y un poco de preferencia hacia otros blogs. Pero aquí voy a retomar el hilo a este blog.

Me ha llegado una consulta, sin pecar por ego, también he recibido otras pero no he podido responderlas y pido disculpas, fué por falta de tiempo y preferencia. La consulta es de William Vidal:

Verás quiero acceder a una base de datos de SQL de manera remota para esto tengo una pc con Ip pública y Windows xp sp2, ahí le he instalado SQL y he creado una base de datos,

Hacer esta aplicación Cliente-Servidor me ha funcionado pero de manera local en una red LAN, pero cuando intento hacía la máquina con ip pública no logro hacerlo, estoy investigando muchas cosas que podrían ser (puertos, instalación de sql), pero quería ver si si me puedes ayudar con algunas cosas primero: mi SO no es SERVER cono Windows server o windows nt.

quisiera preguntarte si para hacer tal cosa necesito de ley que el sistema operativo de la máquina a la que voy a acceder tiene que ser Server.

La cadena con la que me conecto a SQL va más o menos así:

Set cn = New ADODB.Connection

With cn

.Provider = "MSDASQL;DRIVER={SQL Server};SERVER=" & strServer & ";trusted_connection=no;user id= " & strUID & ";password=" & strPWD & " ;database=" & strDatabase & ";"

.Open
La consulta es muy común, voy a tratar de contestar las dudas que tiene William:

1. ¿Es necesario que el sistema operativo sea tipo Server?

No. Es preferible, pero no es necesario. Se puede hacer con Windows XP Profesional.


2. ¿Cuál es la cadena de conexión para este caso?
Provider=sqloledb;Data Source=190.190.200.100,1433;Network Library=DBMSSOCN;Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;
Es importante indicar la librería a utilizar, en este caso DBMSSOCN.

3.¿Hay que abrir algún puerto en el router?

Sí, hay que hacer un forwarding del puerto 1433 en el router, el puerto por defecto de Sql Server, hacia la IP local del servidor Sql Server.

Espero sea de ayuda para William y a otros.

Fuente:
CONNECTION STRINGS

Autor: Carlos Mayanga

Enlaces de ayuda para programar Visual Basic y Sql Server en un Pocket PC 2003

Recientemente he terminado un desarrollo pequeño para la plataforma móvil, especificamente un Pocket PC 2003, HP iPaq, con un cliente hecho en Visual Basic .Net 2005 contra una base de datos Sql Server 2000.

El desarrollo fue interesante, hace algunos años había hecho algo básico, esto fué un poco más complicado. Entiendo que debe haber otras tantas personas igual que yo que buscan información respecto de esta plataforma, por eso listo a continuación los sitios web con los que poco a poco me ayude a desarrollar:

Data Points: Acceso a datos desde una aplicación móvil. Explica detalladamente el acceso desde una aplicación móvil a un origen de datos como SQL Server 2000. Con el NET Framework es sencillo y fácil
Programar con NET Compact FrameworkSección de la librería MSDN para programación en NET Compact.
Todo Pocket PC: Ayuda para conectar Pocket PC a SQL 2000
iPaq rx1950Un bloggero da su opinión respecto de un iPaq similar al que iba a implementar mi programa, y comparte conmigo la opinión sobre la facilidad para desarrollar aplicaciones con el NET Compact Framework.


Entradas Relacionadas:

Auditoría en Bases de Datos Sql Server

Estoy recibiendo algunas consultas a través del correo electrónico, y trato de responder lo mejor posible, a pesar que prefiero que dejen un comentario en uno de mis blogs y otra cosa es que no me apuren, los deseos de ayudar son grandes, pero no el tiempo, que siempre queda chico, este mes de Marzo ha sido muy ocupado y he descuidado mis blogs, dandome cuenta que he disminuido la cantidad de entradas, cuando mi intención era aumentarlas. Pero hoy día trataré de responder a una interesante consulta hecha por un lector, que pregunta cual sería la estructura de una tabla de auditoría para una base de datos.

La primera forma: Añadir campos a una tabla



El modo más simple de auditar una tabla es registrando cada cambio fila por fila, sin embargo también es la menos recomendable. Se basa en añadir uno o dos campos testigos que registren la fecha en que se realizen cambios y el usuario que los efectúe, sin embargo cambios en cada columna no son registrados ni auditados, sólo se registra el último usuario que haya hecho un cambio. Por ejemplo si Pilar hace un cambio en la columna "Precio" y luego Juan cambia el valor de la columna "Cantidad" sólo quedará registrado que Juan hizo un cambio. Este tipo de auditoría es algo ingenua pero que puede servir en algunos casos.

Una segunda forma: Triggers y Tablas Espejo


Sql Server tiene en los triggers (desencadenadores o disparadores) una ayuda para llevar a cabo registros de auditoría. Esta forma tiene el siguiente procedimiento:
1. Crear una tabla espejo con los mismo campos que la tabla auditada pero con campos adicionales, como el usuario que haya hecho el cambio, la fecha y la operación realizada que puede ser fila agregada, fila modificada o fila eliminada.
2.Añadir triggers INSERT, UPDATE y DELETE a la tabla origen, de modo que al efectuarse cualquiera de las operaciones indicadas, grabe el mismo registro en la tabla de auditoría, incluyendo los campos de auditoría (usuario,fecha,tipo de operacion).
Esta forma de auditoría, si bien es mejor que la anterior ya que registra cada cambio realizado y almacena un historial completo para cada fila, impone una sobrecarga de operaciones por cada fila, ya que se vuelve a registrar la misma fila con datos adicionales en caso sea insertada, actualizada o eliminada. Y a la vez aumenta el espacio a ocupar.

Manejar datos de auditoría


El almacenar datos de auditoría ocupa una gran cantidad de espacio en disco duro, y manejar esa información se hace muy complicada, especialmente si se realiza con tablas espejo. Hay que saber manejar esa información, y auditar las tablas necesarias.
Una forma de manejarla es almacenando la información de auditoría en otra base de datos. Se crea una base de datos, y preferiblemente almacenarla en otra partición u otro disco duro si la actividad es intensa. Esto aumenta la complejidad de la auditoría, ya que hay que propocionar permisos a los usuarios para grabar información en la segunda base de datos. Se podría crear una vista en la base de datos auditada que muestre los datos en la base de datos de auditoría para darle un nivel de abstracción.

Archivamiento


Generar información de auditoría es un problema para el espacio, y generar mucha data es peor aún. Hay que diseñar un plan de archivamiento de esos datos, no tenerlo es lo peor que se puede hacer.
Un plan de archivamiento podría ser simplemente separar la base de datos de auditoría y crear una nueva. La desventaja sería el extraer información de la base de datos separada. Otra sería programar un script que extraiga o inserte la información, según sea el caso, y grabarla en cintas o cd. En cualquier caso la recuperación y volcado se hace manual y complica la tarea.

Conclusión


Generar data de auditoría en una base de datos es una ventaja y a la vez un problema ya que acarrea costos en espacio de almacenamiento y tiempo en manejarla. Pero aún así es necesaria en ciertas actividades, especialmente la financiera. Como recomendación, la auditoría debería realizarse a ciertas tablas de una base de datos y no a todas, ya que complicaría aún más el proceso de administración.

Arrays y Listas en Sql Server

El manejo de arrays (arreglos) y listas es complicado y generalmente hay problemas para muchos principiantes. En este artículo en inglés, por Erland Sommarskog, SQL Server MVP, proporciona una explicación excelente que incluye ejemplos indicado lo correcto y lo incorrecto que se realiza cuando se trabaja con arrays y listas.

Hay dos versiones:

Arrays y Listas en Sql Server 2000/7/6.x

Arrays y Listas en Sql Server 2005

Programar para Pocket PC 2003: Como probar una aplicacion que desarrollemos

ActiveSync y Emulador de Dispositivos

Anteriormente publique una entrada donde colocaba algunas conclusiones que había sacado cuando había estado programando una aplicación Visual Basic .Net 2005 en una HP iPaq con Pocket PC 2003. Cuando se programa siempre es importante ir probando el programa para ir depurandolo, seria ideal tener el dispositivo para realizar las pruebas pertinentes, pero en ocasiones no es posible contar con tales recursos y hay que probarlos en un emulador, como fue mi caso.

Primero necesitamos el programa Microsoft Active Sync que se puede descargar desde la página de Microsoft. ActiveSync permite crear una relación de sincronización entre el dispositivo móvil y su PC mediante un cable, un soporte de conexión, la tecnología Bluetooth o una conexión de infrarrojos. ActiveSync también posibilita la conexión del dispositivo a otros recursos a través de su PC. Sin embargo, no permite sincronizar de forma remota con un equipo mediante una conexión de red o módem.



Hay que configurar adecuadamente a ActiveSync para que permite la prueba de la aplicación. Hay que ir al menú Archivo, Configuración de Conexión, y establecer DMA para que el dispositivo virtual se pueda conectar.



El emulador viene con el Microsoft Visual Studio 2005. Se llama el Administrador de emuladores de dispositivos, y se encuentra en el menú Herramientas.



En la ventana del Administrador de emuladores de dispositivos se muestran todos los dispositivos que se pueden emular. Según el dispositivo se elige la opción correcta, para mi caso que fue una Hp iPaq con Pocket PC 2003, elegí la opción Pocket PC 2003 SE - Emulador, que correspondía al equipo que era el destino de mi aplicación.



Se hace clic con el botón derecho del mouse y se hace clic en la opción Connect o Conectar, según el idioma. Se abrirá una ventana con la imagen del equipo a emular (no será realmente igual, pero emulará la funcionalidad). Y en el Device Manager, aparecerá un icono de flecha verde que indica que el dispositivo virtual está ejecutándose.



Aún así, todavía falta un paso más para poder probar la aplicación. Nuevamente en el Device Manager hay que hacer clic derecho sobre el dispositivo, y hacer clic en Cradle. Esta opción conectará el dispositivo virtual al ActiveSync, y conectará "en red" al dispositivo y la computadora.

Saldrá un cuadro de diálogo pidiendo establecer el tipo de asociación, para las pruebas es necesario solamente Invitado.





En la ventana de ActiveSync se puede hacer clic en el botón Explorar y se puede ver las "carpetas" del dispositivo virtual.



Luego de establecer estas opciones, ya se puede probar la aplicación, haciendo clic en Generar. Saldrá la ventana, pidiendo elegir donde se va a implementar la aplicación, hay que elegir la opción Pocket PC 2003 SE - Emulador,y hacer clic en Implementar.



Eso seria todo, si tienen alguna duda dejen un comentario.

Entradas Relacionadas:

Política de Privacidad del Blog

Política de Privacidad de Blogs de la Red Ikanus

En los blogs de la red Ikanus reconocemos que la privacidad de su información personal es importante. No vendemos su información personal a terceros, simplemente se comparte de forma anónima.

Archivos de registro

Como la mayoría de los sitios web, recolectamos y utilizamos los datos contenidos en nuestros archivos de registro. Dichos datos incluyen su dirección IP, su servidor de acceso a Internet, su navegador, la fecha en que nos visitó y cuáles páginas de la red de Blog Ikanus visitó, entre otros.

Cookies y Publicidad

Utilizamos “cookies” para almacenar cierta información, tal como sus preferencias al visitar nuestro sitio web.

En la red de Blog Ikanus también ofrecemos publicidad de terceros. Algunos de dichos anunciantes, a través de Google Adsense y otros, pueden usar cookies u otras tecnologías al publicitar aquí, y así­ recibir información como la descripta en el apartado anterior.
Actualmente este sitio alberga publicidad de:
Google Adsense: http://www.google.com/intl/es_ALL/privacypolicy.html
Usted puede elegir deshabilitar nuestras cookies o las de terceros desde la configuración de su navegador u otras aplicaciones. Sin embargo, ello podría afectar su capacidad de interactuar con éste y otros sitios web.

Es necesario mencionar que estos datos no perjudican ni recopilan información suya personal. Simplemente recaban tendencias en las preferencias de la navegación.

Google, como proveedor asociado, utiliza cookies para publicar anuncios en su sitio. Los usuarios pueden inhabilitar el uso de la cookie de DART a través del anuncio de Google y accediendo a la política de privacidad de la red de contenido.

Publicidad Basada en Intereses


Google utiliza empresas publicitarias asociadas para publicar anuncios cuando los usuarios visitan nuestro sitio web. Es posible que estas empresas usen la información que obtienen de las visitas a este y a otros sitios web (sin incluir nombre, dirección, dirección de correo electrónico o número de teléfono) para ofrecer a los usuarios anuncios sobre productos y servicios que les resulten de interés. Si desea obtener más información sobre esta práctica y conocer las opciones de que dispone para impedir que estas empresas usen dicha información, haga clic aquí.

Web Beacons
Cualquier sitio de la Red de Blog Ikanus puede albergar también web beacons (también conocidos por web bugs). Los web beacons suelen ser pequeñas imágenes de un pixel por un pixel, visibles o invisibles colocados dentro del código fuente de las páginas web de un sitio. Los Web beacons sirven y se utilizan de una forma similar a las cookies. Además, los web beacons suelen utilizarse para medir el tráfico de usuarios que visitan una página web y poder sacar un patrón de los usuarios de un sitio.
Terceros
En algunos casos, compartimos información sobre los visitantes de este sitio de forma anónima o agregada con terceros como puedan ser anunciantes, patrocinadores o auditores con el único fin de mejorar nuestros servicios. Todas estas tareas de procesamiento serán reguladas según las normas legales y se respetarán todos sus derechos en materia de protección de datos conforme a la regulación vigente.
Este sitio mide el tráfico con diferentes soluciones que pueden utilizar cookies o web beacons para analizar lo que sucede en nuestras páginas. Actualmente utilizamos las siguientes soluciones para la medición del tráfico de este sitio. Contacto.
Si tiene preguntas o cuestiones sobre esta Política, no dude en contactarse en cualquier momento a través del formulario de contacto disponible en el sitio o por medio del correo electrónico privacidad@ikanus.com

4 Reglas Simples para manejar valores NULLs

En Sql Server Central, dan 4 reglas para el manejo o utilización de valores NULLs:

Regla #1 : Use NULLs para indicar solamente información desconocida o extraviada. No usar NULLs en lugar de ceros o cadenas de longitud cero u otros valores que representan valores en blanco. Actualizar sus valores NULLs con la información apropiada tan pronto sea posible.

Regla #2 : En Ansi SQL, NULL no es igual a nada, incluso no es igual a otros NULLs. Las comparaciones entre valores NULLs resultan en desconocido, ni verdadero ni falso.

Regla #3 : Usar SET ANSI_NULLS ON, y siempre usar la sintaxis ANSI Standard SQL para NULLs. Alejarse del estándar puede causar problemas incluyendo casos de portabilidad, incompatibilidad con código existente y bases de datos que retornan resultados incorrectos.

Regla #4 : El estandar ANSI COALESCE() y sintaxis CASE deben ser usados sobre ISNULL() u otra sintaxis propietaria.

El artículo en inglés se puede leer aquí.

Sql Server : Informacion del Servidor

Para saber exactamente la versión del Sql Server que tenemos instalado, se puede correr el siguiente script, que nos dará la información necesaria.

set nocount on
go

select @@version
go

select 'Edición: ' + convert(char(20), serverproperty('Edition'))
go

select 'Versión del Producto: ' + convert(char(20), serverproperty('ProductVersion'))
go

select 'Nivel de Producto: ' + convert(char(20),serverproperty('ProductLevel'))
go

set nocount off
go

El dato ProductLevel o nivel de Producto es el Service Pack aplicado al servidor.

Base de datos del Ejemplo

Anteriormente publiqué un ejemplo donde explicaba como conectarse desde Visual Basic 6 al Sql Server 2000, pero olvidé indicar que utilizaba la base de datos Pubs que viene con el Sql Server.

De todas maneras dejo este enlace para que la descarguen.

Descarga de Pubs.

Migrando FoxPro a Sql Server

Kevin Cox ha publicado un artículo en el Blog de Microsoft Sql Server Development Customer Advisory Team sobre su experiencia de migrar una solución FoxPro a Sql Server.

Aquí algunas de las notas acerca de los puntos a tomar en cuenta para una migración:

1. Si se tiene un tipo de datos MEMO en FoxPro deberias usar VARCHAR(MAX) en SQL Server. Podriamos usar TEXT pero sabemos que ya no va a ser utilizado en la próxima versión, y que será sustituida por VARCHAR(MAX). Y VARCHAR(MAX) tiene mejor performance.

2. Hay muchos tipos DATE en FoxPro. La decisión fue fácil de convertirlas a todos a DATETIME en SQL Server 2005. En SQL Server 2008 hay mas tipos DATE, de modo que hay que estudiar como mapear los tipos de datos FoxPro a los nuevos tipos SQL Server 2008. Los datos tipo DATETIME fueron exportados en formato de cadena usando YYYYMMDDHHMMSS.

3. En FoxPro NUMERIC(5,2) permite un rango de -99999 to 99999. En SQL Server usando la misma precision el rango es -999.99 a 999.99. Este fue el unico tipo de datos en el esquema que necesito ser alterado el nivel de tipo de datos. Entonces en SQL Server se usó NUMERIC (7,2) para conseguir el mismo rango.

4. Los campos en FoxPro de tipo LOGICAL fueron exportados como T/F o 0/1. Ellos se convirtieron en un tipo BIT data type en SQL Server o un TINYINT. TINYINT fue elegido si se van a realizar calculos sobre el campo en el futuro; p.e. SUM, AVG, etc.

El artículo completo se puede leer aquí.

Consulta con fechas

Otro problema que a veces nos causa programar contra Sql Server, es cuando se inscrustan consultas dentro del software (por eso siempre es mejor utilizar procedimientos almacenados), cosa que no es lo recomendable, pero que a veces es necesario.

En Visual Basic (versión 2005) tenía la siguiente consulta que habia armado:

Consulta1 = "Update Tabla1 Set Fecha = '" & Fecha & "' Where CodigoId=" + CodigoId.Trim

Es decir vamos a cambiar la tabla Tabla1, la fecha y lo filtramos por CodigoId. La variable Fecha es del tipo Datetime, y la obtenemos cuando el usuario elige una fecha en un Datetimepicker del formulario. No se nota bien pero se utilizan comillas simples (') para delimitar la fecha en la consulta.

Si esa consulta, tal como está la ejecutamos utilizando un SqlCommand, nos dará un error, diciendo que no se pudo efectuar la conversión de cadena a datetime.

El error se debe a que al guardar el valor del DatetimePicker en la variable Fecha, se guarda con hora también, y ese dato al parecer no permite ejecutar la consulta. Ahora solo ponemos en la consulta la parte de la fecha y el mensaje de error no volverá a salir, y la consulta se ejecutará correctamente.

Consulta1 = "Update Tabla1 Set Fecha = '" & Fecha.ToString.Substring(0, 10) & "' Where CodigoId=" + Codigo.Trim

Parece sencillo, pero me tomó unos minutos descubrir la forma de solucionarlo.

Visual Basic y Sql Server con Ado Data Control

Introducción

Este artículo es una respuesta a una petición de ayuda de un lector. Necesitaban un ejemplo acerca de como conectar Visual Basic 6.0 a Sql Server, él tiene un sistema hecho en Visual Basic que se conectaba a una base de datos Access, utilizando el Data Control. He utilizado en este ejemplo Visual Basic 6.0 (con Service Pack 6), y Sql Server 2000 (Service Pack 4).

Lamentablemente, el Data Control no permite el acceso a bases de datos Sql Server directamente, y no utilizan ADO, que es mucho más eficiente que DAO para acceder a Sql Server.

Desarrollo del Ejemplo

Se tendría que utilizar ADO Data Control (ADODC) para realizar un ejemplo lo más similar a lo que utiliza actualmente en su software. El ADODC es muy similar al Data Control, para poder utilizarlo en el proyecto, hay que agregar el componente como se ve en la imagen (hacer clic para verla).



El diseño del formulario de ejemplo es simple:



Los primeros campos, permiten al usuario ingresar el nombre del Servidor, el nombre de la base de datos, el usuario con los permisos suficientes para acceder a la base de datos y la contraseña del usuario.

Hay un botón "Conectar", que hay que pulsar para establecer la conexión al servidor y a la base de datos. Al conectarse, se ejecuta una consulta inicial que rellena el datagrid con los datos recuperados.

Luego hay un campo de texto, donde se ingresará un nombre o una parte para filtrar los registros de la tabla. Hay una etiqueta donde se da el ejemplo. El ADODC se ve en modo diseño, pero en tiempo de ejecución está oculto por defecto, se puede cambiar, tal como lo hice en el ejemplo.

En esta imagen se muestra el formulario, cuando se pulsa el botón "Conectar" con los parámetros correctos, se listan los registros de la tabla employee.



Y ésta, muestra cuando se ha hecho una consulta filtrando por la palabra "an", se muestran solo los registros que contienen dentro del nombre dicha palabra.



El siguiente es el código del botón "Conectar"

Private Sub cmdConectar_Click()

Dim CadenaConexion As String

CadenaConexion = "Provider=SQLOLEDB.1;Persist Security Info=False;User ID=" + txtUsuario.Text + ";Password= " + txtPassword.Text + ";Initial Catalog=" + txtBaseDatos.Text + ";Data Source=" + txtServidor.Text


With adoEjemplo

.ConnectionString = CadenaConexion

.CommandType = adCmdText

.RecordSource = "SELECT * FROM employee"

.Refresh

End With


With DataGrid1

Set .DataSource = adoEjemplo.Recordset

.Refresh

End With


cmdConectar.Enabled = False


End Sub




Y el siguiente es el código del botón "Buscar":

Private Sub cmdBuscar_Click()

Dim Consulta As String

Consulta = "Select * from employee where fname like '%" + txtConsulta.Text + "%'"


With adoEjemplo

.RecordSource = Consulta

.Refresh

End With


With DataGrid1

Set .DataSource = adoEjemplo.Recordset

.Refresh

End With


End Sub


Conclusión

Como se ve el código no es muy complicado, y es muy similar a lo que se usaría en consultar una base de datos Access, claro que es un ejemplo, y le falta mucho para ser considerado en producción, como control de errores, y otros controles de seguridad. Además, utilizar ADODC en una solución profesional, no es recomendada, como dice la propia Microsoft, es útil para prototipos, no para una solución real.

Descarga desde aquí el código completo.

ACTUALIZADO: Olvidé indicar que la base de datos de ejemplo era la Pubs que viene por defecto con el Sql Server. Si ya la borraron o no la tienen la pueden descargar de aquí.

Espero sea de ayuda para el lector, y también para otros.

Carlos Mayanga

Mis otros blogs:
PCT: Programación y Tecnología
Sistémico en Apuros
Ciudad de Chiclayo: Tienes que conocerla

9 peligros de seguridad en Sql Server

En SearchSqlServer.com dan una lista con los 9 peligros de seguridad más comunes en el trabajo de un administrador de bases de datos:

  1. Ejecutar aplicaciones con privilegios de administrador y dejar al front-end controlar la seguridad del la base de datos.
  2. Los administradores de bases de datos usan cuentas de nivel de administrador para las tareas diarias que no requieren tales privilegios.
  3. Multiples administradores tienen en sus manos los mismos sistemas.
  4. Se comparten las cuentas de administrador de Windows para manejar la base de datos.
  5. No se usan procedimientos almacenados donde son posibles.
  6. No se crean vistas de la base de datos basadas en permisos de usuarios o grupos.
  7. Los registros de auditoría no son revisados.
  8. Multiples administradores para la administración del almacenamiento y copia de seguridad de la base de datos.
  9. Nula o casi inexistente clasificación para ubicar a cada base de datos sobre el mismo nivel de importancia.
Leer el artículo original.

Documentar una base de datos

Para documentar una base de datos, hay que hacerse las siguientes preguntas, y sobre las respuestas se va redactando la documentación, hay que recordar que la documentación se hace mientras se va diseñando la base de datos, si uno olvida de documentar algo, le harás la vida dificil a quien vaya a trabajar contigo, o lo que es peor, a tí mismo.

¿Por qué una tabla en particular es creada?

¿Qué es lo necesario de una columna en particular?

¿Para que usamos el procedimiento almacenado XYZ?

¿Que ha sido efectuado cuando un procedimiento ha sido ejecutado?

Hay muchas herramientas automtizadas para realizar la documentación de una base de datos, especifícamente para Sql Server hay decenas, casi todas de pago, lo más sencillo es utilizar Word o un procesador de textos, para ir documentando la base de datos.

Caso raro de Vistas en Subconsultas

Esto es un caso raro cuando se utilizan vistas. Generalmente se usan las vistas para disminuir la complejidad de las consultas. Y aveces se cambian los nombres de las tablas base que se usan con el mismo proposito.

Veamos que es lo raro. Si tenemos una vista, como la siguiente:

CREATE VIEW dbo.view_ajustes
AS
SELECT
dbo.Puntosventa.nombre AS PuntoVenta, dbo.productos.nombre AS ProductoVenta, dbo.ajustes.preciounitario AS Precio, dbo.ajustes.cantidad
FROM PuntosVenta inner join Productos on PuntosVenta.IdPuntoVenta = Productos.IdPuntoVenta inner join ajustes on productos.idproducto=ajustes.idproducto


Si se quiere realizar una consulta a esa vista:

select puntoventa,productoventa,preciounitario,cantidad
from view_ajustes


Se ejecuta sin error, dando como resultado las filas deseadas. Ahora utilizaremos la vista en una subconsulta.

select *
from puntosventa
where nombre in (select nombre from view_ajustes)


Esta consulta se ejecutará sin errores. Pero chequeenla. En la subconsulta se está utilizando la columna 'nombre' que no existe en la vista view_ajustes y no el campo 'puntoventa'. Aún así no hay errores y Sql Server puede "descifrar" a traves de la vista el nombre de la columna en la tabla base. Pues la columna 'nombre' si existe en la tabla base puntosventa.

Es más como en la misma vista se utilizan dos columnas con el mismo identificador 'nombre' de dos tablas diferentes, la anterior consulta se puede modificar para consultar la tabla productos, sin errores también.

select *
from productos
where nombre in (select nombre from view_ajustes)


Conclusión: Debe ser una "característica" en Sql Server 2000 (también pasa si prueban en Sql Server 2005), mediante la cual en una subconsulta que utilizan vistas, no importa utilizar el identificador utilizado en la vista o el identificador de la tabla base.

Fuente:
Sql Server Central.