Paginar nuestras consultas resulta que siempre aligera más la carga del motor de base de datos, siempre y cuando éste tenga los índices donde corresponden y no en cualquier columna o peor aun, no tener indices, ya que sólo se transmiten los datos a mostrarse en el momento, ésta característica se siente mucho mejor cuando estamos trabajando con aplicaciones web, u otras que corran sobre una red de baja velocidad o alta concurrencia. De ahí su gran implementación en los últimos tiempos.

Para lograrlo necesitamos de la ayuda de nuestro motor de base de datos, ésta vez veremos el ejemplo en 4 motores muy populares, SQL Server, Oracle, MySQL y PostgreSQL. Personalmente creo que es más sencillo implementarlo en MySQL y PostgreSQL, seguido de Oracle y SQL Server. Aunque esto no hace que (Continuar Leyendo sobre Realizar Consultas Paginadas en SQL Server, MySQL, Oracle & PostgreSQL)

Las siglas UDF viene del inglés User Defined Functions (Funciones Definidas por el Usuario), esto quiere decir que podemos crear funciones personalizadas para hacer un determinado proceso que utilizaremos en más de una ocasión, luego tan sólo deberíamos invocarlo para volver a utilizarlo. En Transact-SQL existen 3 tipos de funciones:

1. Funciones Escalares
2. Funciones en línea
3. Funciones en línea de múltiples sentencias

Para ver en acción esto, crearemos una base de datos (versión 2008 por el tipo de dato date que no es soportada en versiones anteriores) con una tabla y datos de ejemplo (Continuar Leyendo sobre Crear e Invocar funciones (UDF) en SQL Server)

Siguiendo la temática de las cadena de conexión de los motores para los distintos lenguajes, ya hemos visto para Oracle, ahora veremos para SQL Server. (Continuar Leyendo sobre Cadena de Conexión de SQL Server)

Cuando trabajamos con SQL Server con aplicaciones clientes escritas en el lenguaje de programación que sea y usamos transacciones controladas con try..catch, podríamos llegar tener problemas si no lo hacemos del modo correcto.

Me explico mejor con un ejemplo práctico, supongamos que tenemos una aplicación de facturación y queremos eliminar una factura, para salvaguardar la integridad de nuestros datos lo más lógico es crear una transacción dentro del procedimiento que hará la baja, así por si ocurre un error en el eliminado del detalle de la factura, no borramos la cabecera, o si ocurre el error al eliminar la cabecera, deshacemos el eliminado previo del detalle para que todo quede como estaba anteriormente. Hasta este punto todo es muy bonito, si en el procedimiento declaramos la transacción controlada por un bloque try y dentro del catch hacemos sólo el rollback, la aplicación nunca se dará por enterada que en la base de datos hubo algún problema, y si éste emite un mensaje de proceso satisfactorio, lo hará incluso cuando tengamos errores. ¿Por qué esto? Simple, la excepción no se expandió desde la base de datos y no pudo ser capturada (Continuar Leyendo sobre Capturar error en SQL Server y volver a Lanzarlo)

Éste probablemente sea uno de los post mas raros que escribiré, todo programador cristiano sabe que ASP.net se despliega oficialmente sobre el servidor web de Microsoft IIS, necesitando necesariamente un servidor Windows. Hoy haremos lo que muchos desean, lo que muchos dicen ser imposible, o lo que muchos solamente quieren experimentar, haremos una mini aplicación escrita en C#.net y ASP.net, que se conecte a un servidor de base de datos SQL Server, desplegandolo sobre Apache Tomcat en GNU/Linux.

Existen mods del proyecto mono para instalar sobre Apache que permiten correr ASP.net sobre él, pero no es precisamente eso lo que usaremos, sino algo más extravagante.

¿Y cómo se supone que haremos esto? La empresa Mainsoft (apoyado por Novell) ofrece un producto que forma parte de una comunidad, con licencia openSource, llamado (Continuar Leyendo sobre Desplegar ASP.Net en Apache Tomcat sobre GNU/Linux y SQL Server)

Uno de los tantos problemas de desarrollar en Grupos de Trabajo grandes, es la manera en la cual codifican los demás Compañeros de Trabajo, o que no se respeten al 100% las Políticas de Desarrollo y Codificación de la Empresa / Grupo de Trabajo, para los Scripts y Procedimientos Almacenados o Triggers de nuestras Bases de Datos en SQL Server.

Para facilitar las cosas, muchas veces las herramientas como el SQL Query Analyzer y SQL Server Management Studio del SQL Server 2005 / 2008, nos presentan las “Plantillas de Código” (pequeños pre-armados de código Transact-SQL listo para modificarse y ser usado para nuestros fines).

Pero a veces nuevamente esas plantillas no tienen el formato que deseamos, y necesitamos adecuarlas a ellos.

Una manera de estandarizar esos formatos, es ubicando las plantillas y modificarlas, (Continuar Leyendo sobre Plantillas de SQL Server Customizadas)

Como todo buen diseñador de base de datos sabe, es bastante común encontrarse con entidades recursivas en el diseño de nuestra BD, 2 ejemplos típicos son el jefe y el subordinado, en el diseño ambas personas se encuentran registradas como tuplas dentro de la entidad Persona o Funcionario (según el diseño que hemos tomado, incluso estaría mejor diseñado si se lo hace en base al cargo), al no existir 2 entidades que tengan cardinalidad 1:M, por que así obtendríamos duplicación de datos, debemos determinar un modo que ambos estén en la misma entidad y a su vez tener la capacidad de controlar quién es jefe de quién, esto se lograría agregando una columna más que sea del mismo dominio que su propia PK, es decir, la columna nueva sería FK de la PK que le determina, logrando así una cardinalidad 1:M recursiva.

Otro ejemplo típico es el caso de los contratos, estos suelen tener la característica que vencen en una fecha determinada, por cuestiones de ventas/marketing al cliente se le facilita normalmente este proceso con una renovación de contrato (Continuar Leyendo sobre Realizar Consultas Recursivas en SQL Server)

Este tema de LINQ produjo su conmoción desde que apareció como herramienta de rápido desarrollo para mapeo ORM, es decir, crear una abstracción de las tablas de nuestra base de datos en clases para nuestra aplicación, una tabla – una clase.

Por ser un concepto relativamente nuevo, no quiere decir que sea complejo implementarlo, al contrario, es más sencillo y veloz el desarrollo de este modo. Personalmente me recuerda cierta tecnología de java. (sólo cierta semejanza ya que su implementación no es igual).

Primeramente para nuestro ejemplo necesitaremos una base de datos de ejemplo, (Continuar Leyendo sobre Un ejemplo sencillo y entendible de LINQ con C#)

Un Servidor Vinculado sirve para que el motor de base de datos (en este caso SQL Server) pueda tener acceso a otra BD para hacer consultas distribuidas, ejecutar Stored Prochttp://www.devtroce.com/wp-admin/edit.phpedures, entre otros, digamos de un modo “transaparente” ya sea del mismo proveedor o no.

Para lograr esto necesitamos un proveedor de datos OLEDB y definir su cadena de conexión, a la par de asignarle un nombre lógico, el cual será usado para su invocación directa. Una vez definido esto podemos utilizarlo de manera abstracta para conectarnos a otras fuentes sin necesidad de volver a escribir toda la cadena de conexión. Crear esto con otro motor o instancia de SQL Server es relativamente sencillo, por lo tanto me centraré más bien en hacerlo con el motor de otro fabricante, en este caso Firebird, el cual fue el que más problemas me dió, con MySQL y PostgreSQL incluso fue más sencillo.

Oficialmente Microsoft da soporte para crear Linked Servers contra SQL Server y Oracle, (Continuar Leyendo sobre Configurar Linked Server con SQL Server y Firebird)