Problemas con Inserción desde Procedimientos almacenados al recuperar las claves o cuando usar @@identity Scope_Identity() o Ident_Current()

Buenas a tod@s

Hoy voy a contaros un par de cosillas de los procedimiento almacenados que os puede ser de gran utilidad. Muchas veces, nosotros manejamos la base de datos a través de procedimientos almacenados, ya que es más seguro, ofrece buenas herramientas de análisis, separamos el grueso de acceso a datos del resto de aplicación, permite que modifiquemos sentencias sin tener que generar una nueva publicación… y cualquier otra razón que a vosotros os guste más.

Uno de los problemas que nos enfrentamos a la hora de insertar un nuevo registro, es al devolver la clave del registro insertado, ya que este puede ser que asigne de forma automática. Muchos de nosotros utilizamos el parámetro @@identity para este fin, pero puede que no sea buena idea, ya que es posible que no devuelva en índice correcto.

Existe tres formas de obtener la clave y cada una tiene sus particularidades:

Scope_Identity(): Devuelve  la clave de la última inserción dentro del procedimiento almacenado en el que lo estamos ejecutando.

@@Identity: Devuelve la clave de la última inserción, a nivel de sesión. Esto quiere decir que si después de la inserción se ejecuta un trigger, al recuperar el valor de la clave, devolverá la clave del trigger y no la del procedimiento almacenado donde lo ejecutamos.

Ident_Current(): Devuelve la última clave introducida sin tener en cuenta sesiones. Es decir, si por ejemplo estamos introduciendo datos con dos usuarios a la vez devolverá la clave de la última inserción independientemente del usuario que lo haya insertado. Es probable que ambos reciban el mismo valor si la inserción ha sido simultánea.

Como podéis comprobar, cada una de las funciones está delimitada de una forma muy concreta. Es posible que para ciertos casos nos interese una u otra, eso tendremos que verlo en su contexto. Lo que está claro es que en muchos casos utilizamos @@identity cuando no es correcto y puede producir un gran problema de coherencia en los datos.

La información a sigo extraída de http://technet.microsoft.com/es-es/library/ms187342.aspx

Espero que este tema haya resultado interesante, no muy aburrido, que ahorre un susto a más de uno y sobre todo que sirva para algo.

Muy importante, si decides comentar o republicar parte de este articulo porque te ha sido útil, por favor cita la fuente y el autor del mismo (vamos cítame) y pon un enlace al artículo de mi blog

Muchas gracias por leerme.

Saludetes a todos

P.D. Podéis seguirme en Twitter @jberron y LinkedIn

SteamOS el nuevo sistema operativo de Valve ¿Que puede suponer para Linux?

Buenas a tod@s

Hoy voy a hablaros de noticias fresquitas, fresquitas de Linux y de Juegos todo en un mismo artículo, haciendo una reflexión a futuro.

Evidentemente son conclusiones propias, lo cual no quiere decir que realmente se cumpla ninguna de ellas (desafortunadamente para mi economía no soy Rappel, ni la Bruja Lola…).

Historia de los juegos en Linux

Linux y los juegos son dos palabras que no suelen ir nunca juntas. ¿Por qué? Bueno básicamente porque a día de hoy salvo alguna excepción los juegos comerciales que todos conocemos no salen para Linux. Bien porque las librerías de Linux no son del todo optimas, porque cada distribución funciona de una forma, porque para Windows ya se encarga Microsoft de ofrecer unas herramientas mejores o porque las gallinas ponen huevos. 

Con sinceridad la mayor parte de las escusas son vanas pero la cruda realidad es que el mercado de juegos de pc es para Windows, en algún caso (cada vez mas) también para OSX pero para Linux realmente aparecen muy pocos títulos y menos famosos y comerciales. A día de hoy no existe por ejemplo un Diablo III, un StarCraft 2 o un GTA para Linux. Por lo tanto la mayor parte de los juegos que existe para Linux son juego o bien sencillos en plan mini juegos, algunas adaptaciones de juego antiguos (como Quake III), o títulos de tipo indie.

Y aparece Valve

No sé si a día de hoy existe alguien que no conozca a Valve pero por si acaso os voy a contar un poco sobre los inicios de esta singular empresa con ese peculiar crédito en sus juegos. 

Valve es una empresa americana creada haya por el año 1996 y en 1999 apareció su primer juego Half-Life. Si alguien no ha jugado a este título… debería hacerlo. Es posiblemente uno de los mejores juegos que existen para pc, quizá a día de hoy sus gráficos está ya muy anticuados y su mecánica es básica, pero en el año 1999 fue totalmente rompedor, con un historia digna de una gran película de acción y conspiraciones. 

La historia comienza con un nuevo empleado llega a Black Mesa Doctor en Física llamado Gordon Freeman y al realizar su primer experimento, la cosa no sale precisamente bien…o sí... ahí lo dejo para el que quiera saber el resto de la historia que juegue a este juegazo.

Pero no fue el juego en si sino el éxito vino después, Valve dejo abierta una puerta para que cualquiera pudiera crear de una forma más o menos sencilla un juego basado en su juego, es decir, un Mod. Un tiempo después apareció un pequeño Mod hecho por unos aficionados en el que te enfrentabas con otros jugadores en red local u online (si he dicho online) en el que podías ser un terrorista o un antiterrorista y completar diferentes misiones, si no lo habéis adivinado ya hablo de Counter-Strike. 

La gracia era que el mod lo descargabas gratuitamente y solamente tenías que tener una licencia de Half-Life para jugar online. Gracias a que Half-Life era un juego barato y que sus requerimientos eran bajos para la época en la que salió el juego reventó en ventas y Valve gano mucho dinero.

Valve crea Steam

Tiempo después, en Septiembre de 2003, Valve creo la plataforma Steam, la cual no es más una tienda para juegos al más puro estilo AppStore, Google Play o Windows Marketplace (de hecho estoy seguro que estos se inspiraron en el funcionamiento de Steam para crear sus plataformas). 

Evidentemente  Valve puso todo su catálogo de juegos en esta plataforma, de tal manera que si para jugar al Counter-Strike o Half-Life, podías descargar Steam e introducir tu número de serie y automáticamente tenías el juego dentro de la plataforma. Esta también se encargaba de actualizar los juegos a las últimas versiones etc etc. Esta plataforma a día de hoy solamente distribuye juegos y ofrece grandes facilidades para la publicación a cualquier desarrollador (os suena de algo verdad). Actualmente su catálogo tiene más de 2200 juegos.

Steam llego a Linux 

Como toda empresa que se precie, Valve intenta que su plataforma sea capaz de ejecutarse en cualquier ordenador. La versión para Windows salió en el año 2003, pero en ese momento Linux era mucho más minoritario que ahora y tenía muchos problemas con la aceleradoras graficas 3D (a día de hoy, ya no existe tarjetas sin aceleración 3D, antiguamente una tarjeta gráfica no tenía porque tener aceleración 3D, por lo que llamar tarjeta gráfica a una aceleradora 3D es incorrecto, hoy en día estos dos términos se entienden como uno no siempre fue así, la culpa de unirlas la tuvo la genial 3DFX y NVIDIA) y los drivers privados que no existían para Linux. 

Afortunadamente para Linux esta época ya pasó y cada día son más los fabricantes de tarjetas gráficas que tienen drivers para Linux que funcionan correctamente (aunque muchas veces no bien optimizados, al menos funcionan). En Febrero de 2013 Valve creo una versión  de su plataforma Steam para Linux la cual va acompañada de 50 juegos. Ya no es necesario tener Windows en tu portátil para jugar a Half-Life o Counter-Strike lo puedes hacer desde tu Linux favorito. La arriesgada apuesta de Valve ha sido todo un acierto y además funcionando muy bien en ventas.

SteamOS

La noticia es de hace aproximadamente una semana, en la que Valve acaba de anunciar SteamOS.

 

¿Qué es SteamOS? 

En pocas palabras, es una distribución de Linux gratuita, creada y mantenida por Valve y optimizada para juegos. Es decir, Valve ha cogido Linux y lo ha adaptado para que su plataforma Steam funcione perfecta. Al decir que Steam tiene que funcionar perfecta, nos referimos a que los juegos que están en Steam correrán de forma perfecta. Además el hardware es actualizable y está pensado para utilizar pantallas grandes, no es por desechar los monitores de 19 o 21 pulgadas que tenemos, sino de poder utilizar de una forma cómoda nuestra tv de 40. La idea es convertir el ordenador en una especie de consola de videojuegos.

Que puede aportar SteamOS a Linux y al revés

La idea es muy buena, pero tiene varios problemas, por un lado, los ordenadores no son todos iguales por lo que hay disparidad de componentes a tutiplén. Linux tiene la ventaja de que soporta casi cualquier cosa, desde una terminal para fichar, hasta el más complejo de los sistemas que se envía a marte y por eso se aprovecha Linux ya que funcionará casi en cualquier equipo. Además Valve sacara un equipo modelo, pero aun así nos darán la oportunidad de utilizar y montar el que nosotros queramos o incluso ampliar el de modelo con una mejor grafica o más RAM. 

El problema son los drivers de los nuevos dispositivos. Actualmente como sabéis el mercado del pc no está en su mejor momento, y si hablamos de sobremesas o torres, menos aún, por lo que el mercado de estos equipos prácticamente está en los jugadores. Si SteamOS tiene tirón los fabricantes de componentes se van a ver obligados a lanzar drivers de sus más avanzados dispositivos a la vez que el propio dispositivo para SteamOS o perderán muchas ventas. Si lo diseñas para SteamOS, finalmente lo estás diseñado para Linux, por lo que lo usuarios del pingüino deberían tener muchos menos problemas para obtener buenos drivers para sus equipos y ponerse casi a la par con Windows. Yo por ejemplo, tengo un portátil con sistema Optimus (2 graficas una para juegos y otra para trabajo) y en Linux este sistema no funciona (o al menos no funcionaba). De ahora en adelante si quieren vender componentes los fabricantes tendrán que pensar más en Linux y eso nos beneficia a todos, algunos incluso puede olviden a Windows.

Conclusiones

La plataforma SteamOS se beneficia del funcionamiento de Linux y de sus drivers, pero su éxito puede hacer que Linux se beneficie de drivers más específicos y mejores para cualquier dispositivo por parte de sus fabricantes, liberando así a la comunidad de gran parte de este desarrollo y pudiendo enfocar su esfuerzo en otras tareas, aumentando así es desarrollo del sistema en otros campos.

También puede ocurrir que Valve haga que estos drivers sean propietarios y nos los ofrezca a la comunidad, aunque en este caso también sería tirar piedras contra su tejado, ya que Valve tiene una versión de Steam para Linux que no es SteamOS.

Estos meses se prevén interesantes, ver cómo funciona en ventas SteamBox, en instalaciones SteamOS y cómo reacciona Valve  de cara a la comunidad Linuxera. Muy interesante

Y tú… ¿Qué piensas?

Espero la lectura haya sido amena e interesante

Muy importante, si decides comentar o republicar parte de este articulo porque te ha sido útil, por favor cita la fuente y el autor del mismo (vamos cítame) y pon un enlace al artículo de mi blog

Muchas gracias por leerme.

Saludetes a todos

P.D. Podéis seguirme en Twitter @jberron y Linkedin

Problemas con .Net , Equipos de 64 Bits, Office 32 bits o 64 Bits y aplicaciones antiguas

Buenas a tod@s

Como podéis apreciar ya he vuelto de vacaciones jeje.

La vacaciones muy biejeje. Este verano me he dedicado a viajar por Europa y he visitado Bélgica e Inglaterra. Belgica me ha encantado Brujas es una maravilla y aunque la gente prefiere Gante... Yo me quedo con Brujas. En Inglaterra he visitado Londres y el pueblo más antiguo de Inglaterra, Colchester. Es curioso como una rebelión puede hacer que se moviera la capital del Colchester a Londres... es lo que tienen las rebeliones.

El problema del Office, .NET y los equipos de 64 bits

Bueno volviendo un poco al tajo, os voy a contar un problema que tengo identificado para el cual no tengo una fácil solución. Tengo varias alternativas pero la solución que sería ideal no existe ya me gustaría poderla postear, pero por el momento no es posible y lo creo que lo sea en un futuro.

Cuando desarrollamos una aplicación bajo la plataforma .NET de Microsoft entre todas las opciones que tenemos para realizar la compilación hay una que normalmente pasa desapercibida que es la de CPU. Normalmente las maquinas con las que solemos trabajar a dia de hoy (a menos que sean servidores) suelen ser de 32 bits. Windows XP tiene mucha culpa de esto ya que a día de hoy sigue siendo muy utilizado, pero aunque no tengamos XP también hay versiones de Windows Vista (si ese también existe), Windows 7 o Windows 8 de 32 bits.

Cuando realizamos una aplicación normalmente en la opciones de complicación dejamos la opción de CPU como viene por defecto, es decir en ANY.

No sé si sabéis muy bien como funciona .NET, voy a explicarlo un poco por encima.  Cuando realizas el ejecutable de una aplicación realmente esta aplicación no está compilada en código maquina (como haría por ejemplo C), sino que esta se genera en un código intermedio llamado CLR (Common Language Runtime). La primera vez que ejecutamos la aplicación en la máquina, el Framework de .NET se encarga de compilar este código para generar el ejecutable real. Porque se funciona así, es sencillo, no existe una aplicación más optimizada para una máquina que la que se compila dentro de ella misma. Un buen ejemplo lo tenéis en la distribución Linux Gentoo que al instalarse compila cada uno de los paquetes para que su ejecución sea lo más óptima posible, el problema es que tardas muchísimo en instalarlo. Esa es la razón por la que siempre que ejecutamos una aplicación de .NET por primera vez tarda más en ejecutarse que las siguientes ejecuciones.

Hasta aquí todo correcto, si ejecutamos una aplicación de .NET en la cual no hemos especificado una CPU en un equipo de 64 Bits. La aplicación será compilada en 64 bits y funcionara de forma correcta.

Pero ¿qué ocurre si nuestro programa utiliza Excel o Access para acceder a los datos?

Si tenemos la versión de Office de 64 bits funcionará correctamente, pero si tenemos la de 32 Bits (que Microsoft a día de hoy recomienda) no funcionará. Obtendremos un bonito error diciendo que no se encuentran los controladores específicos de acceso a datos.

Entonces… la solución pasa porque siempre un equipo de 64 bits se instale Office de 64 bits.

Si, esta es una solución, pero… no tan rápido amigo. ¿Qué pasa si tenemos aplicaciones antiguas por ejemplo en VB6 o en C que utilizan los componentes de Office? Creo que lo habéis adivinado, el mismo error que daba la aplicación de 64 bits con el Office de 32.

Evidentemente la solución ideal, sería instalar los controladores de ambos Office, pero esto no es posible a día de hoy y no creo que lo sea nunca, dado que la nueva versión de Office 2013 tampoco lo permite.

http://office.microsoft.com/es-es/support/por-que-no-puedo-instalar-las-versiones-de-32-y-64-bits-de-office-2013-simultaneamente-HA103523746.aspx

La solución que nos queda, es forzar la compilación de nuestra aplicación a X86, es decir a 32 bits, sacrificando algo de rendimiento.

El último de los problemas encontrado, es que si realizamos una publicación mediante ClicOnce y nos encontramos con este problema, debemos realizar una nueva publicación. No vale con recompilar, ya que si republicamos sobre la anterior, no se actualizará en los equipos, porque lo detectará como una versión diferente. Por lo que hay que realizar una nueva publicación y reinstalar todos los clientes.

Como podéis ver, el problema que a priori parece una cosa sencilla, se complica mucho.

Entonces… ¿Qué interesa instalar Office de 32 bits o de 64 bits?

Está claro que si queremos tener compatibilidad con programas antiguos realizados para Windows XP que utilicen el Office, estamos forzados a instalar office de 32 bits. Pero si no tenemos este problema, y todos nuestros programas están hechos en .Net (contra lo que Microsoft recomienda) bajo mi punto de vista es recomendable instalar office de 64 bits. Claro que para esto tenemos que tener en cuenta los programas de terceros que a saber cómo estarán. Si no necesitan acceso a Office y solo los de gestión propia lo necesitan, o sabemos que los que tenemos de terceros lo soportan será mejor así, ganaremos rendimiento y compatibilidad. Pero sino no es estaremos condenados a instalar el de 32 bits y a forzar la compilación a X86.

Mala solución tiene esto, ojala la gente de Microsoft se dé cuenta y busquen una solución porque por el momento no la hay.

Espero que este tema haya resultado interesante, no muy aburrido, que ahorre un dolor a mas de uno y sobre todo que sirva para algo

Muy importante, si decides comentar o republicar parte de este articulo porque te ha sido útil, por favor cita la fuente y el autor del mismo (vamos cítame) y pon un enlace al artículo de mi blog

Muchas gracias por leerme.

Saludetes a todos

P.D. Podéis seguirme en Twitter @jberron y linkedin