generate - Recomendaciones sobre el uso del GUID de SQL Server desde MS Access

order by newid() sql server

Question

Estoy actualizando un backend de MS Access existente a SQL Server 2008 y, como queremos usar la duplicación de Merge de SQL Server , tendré que cambiar todas las claves primarias actuales (enteros de autoincrement estándar actuales) a GUID.

Así que aquí están las preguntas:

• ¿Alguna recomendación sobre hacer el cambio de claves principales de entero a GUID?
• ¿Alguna recomendación sobre el uso y la manipulación del GUID desde el código desde dentro de los clientes de Access?
• ¿Qué tipo de GUID de SQL Server debo usar?

Answer 1

Esto puede ser un poco fuera de tema. Sin embargo, NO TIENE que usar GUID para fusionar la replicación. Todavía puede usar sus enteros de autoincremento y asignar diferentes rangos a diferentes instancias de base de datos. De esta forma, no se generarán filas con identificaciones idénticas.

Además, solo hay un campo de tipo GUID en SQL 2008 - uniqueidentifier

Answer 2

Chris tiene razón al decir que (1) no necesita GUIDS para la duplicación de mezcla y (2) solo hay un tipo de GUID, pero debe saber que:

1. GUIDS se puede generar siguiendo reglas diferentes. Puedes verificar esto aquí
2. Al configurar una replicación, SQL agregará sistemáticamente un GUID (generado como un nuevo elemento secuencial) a cada tabla si aún no existe, y lo llamará rowguid . Por supuesto, si ya tiene un GUID / newSequentialId en cada tabla, SQL lo usará. BUt No recomiendo que "mezcle" GUID de replicación con GUID PK: podría declarar todas sus claves primarias del tipo GUID como ''newSequentialIds'', pero (a) perdería la posibilidad de generar valores GUID en el lado del cliente - ver infra - y (b) tus PK serán entonces ''predecibles'', y esta idea me hace sentir incómodo ...
3. mantener números enteros de autoincrement y administrar su rango a través de la replicación significa una gran cantidad de gastos generales (debe asignar rangos para cada tabla / cada publicación) y una posible fuente de conflictos al replicar desde diferentes fuentes.
4. Además, algunos errores de SQL como este , que son específicos para la asignación de rango, aún no están resueltos adecuadamente: la aplicación del paquete acumulativo 5 no resolvió nuestro problema y tuvimos que encontrar otra manera de reiniciar nuestros procesos de replicación.
5. De todos modos, estoy profundamente convencido de que el cambio de enteros a GUIDs como claves primarias es obligatorio. Hay muchas razones para eso, y una de ellas está vinculada a esta gestión de rango como una fuente potencial de sesiones de búsqueda de problemas y de jaqueca.

Con respecto al cambio de enteros a GUIDS, le aconsejo que escriba un módulo paso a paso que:

• Haga una copia de seguridad de todas las tablas existentes antes de modificarlas
• Agregue un campo GUID a cada tabla
• Agregue los campos FK correspondientes cuando lo solicite
• Actualizar campos FK a través de vistas construidas con las relaciones existentes (construidas en campos enteros)
• Romper relaciones
• Cambiar PK de campos enteros a campos GUID
• Recrear relaciones

Tómese su tiempo para escribir este código. Lo usará muchas veces antes de que funcione correctamente. Debería obtener beneficios del objeto DAO, los tabledefs, los índices, etc. Tenga en cuenta que siempre debe poder volver al punto de partida, así que no olvide el proceso de copia de seguridad inicial.

¿Qué pasa con la manipulación de GUIDs de VBA? Hay algunas cosas que debe saber al respecto:

• Los GUID son del tipo Variant
• Es posible y fácil generar su GUID como clave principal en el lado del cliente de la aplicación, tal como lo propuse una vez aquí .
• Cuando intenta obtener un valor GUID de un control en un formulario (generalmente como el campo vinculado en un cuadro combinado), obtendrá ''?????'' pero no tendrá valor. Debe consultar el valor del campo en el juego de registros para obtener los datos correctos. Puede abrir dicho formulario en su aplicación, ir a la ventana ''inmediata'' y probar esto:

? myForm.myControl
?????

? myForm.recordset.fields("myFieldName")
{000581EB-9CBF-418C-A2D9-5A7141A686CC}

• Puede que tenga que convertir sus guids en cadenas cuando navegue por conjuntos de registros con expresiones como recordset.findfirst:

myFirstRecordset.FindFirst "stringFromGUID(myGuidId) = " & StringFromGUID(mySecondRecordset.Fields("myGuidId").Value)