Identificadores Globales Unicos ... ó GUIDs (por sus siglas en Inglés y pronunciado como Geoduck con el "uck" ó como "Gooo-id" para personas que les cueste trabajo el otro sonido) son básicamente únicos a través del tiempo y espacio. Son usados a través de COM, y son también usados por la replicación Jet como manera para crear un ID para registros que siempre se mantendrán constantes y únicos no importando que otros valores (como los valores de las llaves) cambien.
Mucha gente considera la idea de usar los GUIDs para su llave primaria/valores de llaves foráneas, ya que garantizarán unicidad. Sin embargo, hay muchas razones del porque pensar dos veces antes de bajar por este camino:
1) En una aplicación, un campo de Autonúmero de IDReplicación (i.e. un GUID autonúmero), el cual es entonces convertido en una réplica; Jet utilizará tu columna en lugar de crear una columna s_Guid. Desafortunadamente, el Mago Resolvedor de Conflictos de Access 95 y 97 y el Visualizador de Conflictos de Access 2000 están asumiendo una columna s_Guid y así la resolución de conflicto no trabajará correctamente via el mago; y ahora, te encuentras tú solo, para ver como le haces.
2) Un GUID literalmente es guardado en un valor binario de 16 bytes. También tiene una forma canónica (texto) y también una forma específica DAO/Jet, consistiendo de {guid {xxx}} donde xxx es el valor "canónico". Este último formato es el que Jet desplegará siempre que hagas un selecciona enunciado (select statement) de un campo GUID a través de DAO... se usará la forma canónica si te vas directamente a Jet (como a través de las hojas de datos de Access) ó ADO via el proveedor de OLE DB de Jet (Jet OLE DB provider). Adicionalmente, las reglas de DAO contra los filtros ADO, las búsquedas, las funciones de Dominio Access, filtros por forma de Access, enlaces forma/subforma,...Texto contra el Valor de los límites de control (control bound) a campos GUID, y todos los métodos de búsqueda, son muy difíciles de cambiar y seguir con cada versión. Access tiene funciones ya creadas en ella para ayudar a convertir entre forma canónica y binaria llamada StringFromGUID y GUIDFromString, pero desafortunadamente utilizan la sintáxis DAO, aún cuando todo de COM y la mayoría de las otras fuentes prefieren canónico. Toda esta mezcolanza significa que tratar de usar un campo GUID para estas operaciones significa que le estás pegando a un blanco movible.
3) Las reglas en el #2 cambian con cada versión y casi universalmente rompe con lo que trabajaba en la versión anterior. Así es que escencialmente tienes que volver a revisar todo el trabajo cuando actualices.
4) Los autonúmeros son usualmente hechos visibles a los usuarios, para mejor ó peor, y esto es obviamente muy impráctico para GUIDs, aún si todos los inumerables temas malos con búsquedas y cosas tales como se enlistaron previamente no eran problemas en realidad. Los GUIDs solamente confunden a los usuarios y nadie quiere que un GUID se identifique a sí mismo.
Ahora, es verdad que todos los temas enmarcados en el #2 pueden ser trabajados usando muchas técnicas, incluyendo:
1) Experimentar usando la forma verdadera canónica contra la forma canónica {guid {xxx}}.
2) Uso de conversión vía las dos funciones de Access
3) Usando CStr() en el valor del campo del enunciado de SELECT que regresa GUIDs para que puedas obtener el verdadero formato canónico
4) Tomar nota de todos los lugares en donde hiciste cambios para que cuando actualices puedas recorrer todos esto lugares (la mayoría estarán rotos o cambiados en la siguiente versión).
5) Dándote cuenta de que el campode refuerzo en el caso DAO es un campo de tipo dbGuid y el caso de refuerzo ADO es un campo tipo adGuid... pese a el hecho de que ambos regresan un campo de tipo "texto" cuando solo estás viendo el valor de los campos, ayuda a subrayar el gran esfuerzo por parecer flexibles.... esta es la principal razón porqué el #2 es tan difícil de predecir.
Aquí (por cierto) están funciones que no son de Access para hacer cosas de Guid/String y String/Guid si estás trabajando en VB. Solo cópialas a un módulo, etc.
Type GUID
Data1 As Long
Data2 As Integer
Data3 As Integer
Data4(7) As Byte
End Type
Private Declare Function _
StringFromGUID2 Lib "ole32.dll" _
(rclsid As GUID, ByVal lpsz As Long, _
ByVal cbMax As Long) As Long
Private Declare Function _
CLSIDFromString Lib "ole32.dll" _
(pstCLS As Long, clsid As GUID) As Long
Function GuidFromStGuid(stGuid As String) As GUID
Call CLSIDFromString(ByVal StrPtr(stGuid), _
GuidFromStGuid)
End Function
Function StGuidFromGuid(rclsid As GUID) As String
Dim stGuid As String
Dim cch As Long
' 39 chars for the GUID plus room for the Null char
stGuid = String$(40, vbNullChar)
cch = StringFromGUID2(rclsid, StrPtr(stGuid), 39)
StGuidFromGuid = Left$(stGuid, cch)
End Function
RECOMENDACION FINAL:
Mientras es posible superar ambos temas en el #2 y #3, el #2 es muy problemático y es muy difícil de mantenerlo en la luz del #3 . En general no vale la pena el riesgo de errores ó en forzar problemas de actualización. Hay mejores maneras de escoger PKs que no involucren tales riesgos... así es que casi siempre es recomendable irte por ese camino si quieres escribir una base de datos limpia y fácil de dar mantenimiento así como aplicaciones replicadas.
MichKa
