tag:blogger.com,1999:blog-1297770272282728253.post8863400467988398483..comments2011-04-13T22:16:34.685+02:00Salvador Ramoshttp://www.blogger.com/profile/17812564634015870048noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-1297770272282728253.post-89841032758619790112009-01-05T09:46:00.000+01:002009-01-05T09:46:00.000+01:00Hola Elicx,<BR/>Muchas gracias, me alegro que te haya gustado el post.<BR/>En cuanto a tus comentarios, hay muchos casos en los que no es recomendable el uso de identity. Como cualquier cosa, tiene sus pros y sus contras, en este post sólo me he centrado en explicar cómo funciona. A ver si más adelante escribo sobre casos en los que es recomendable usarlos y otros en los que no.<BR/><BR/>Saludos<BR/>Salvador RamosSalvador Ramoshttp://www.blogger.com/profile/17812564634015870048noreply@blogger.comtag:blogger.com,1999:blog-1297770272282728253.post-33808975090786504312009-01-04T22:15:00.000+01:002009-01-04T22:15:00.000+01:00Muy buen post, pero en bases de datos grandes con filtros dinamicos no funcionan bien ya que las particiones son horizontales o mixtas y dinamicas, en eso caso es conveniente utilizar columnas UniqueIdentifier lo cual hace que el valor sea de 32 Bits imposible de repetirse en la misma base de datos, aunado a esto podemos indicar que el valor por default sea la funcion NewId() lo que la hace que sea similar a identity, y como propiedad del campo le decimos que sea RowID lo que hace que al publicar la base de datos ya no se modifican los articulos al validar las tablas para valores de identificadores unicos. Saludos Elicx Villaseca.Elicxhttp://www.blogger.com/profile/11669911044215159534noreply@blogger.com