Desarrollando con Microsoft Access para Tablets – El campo clave (3)

Hace demasiado tiempo que dejamos esta serie en standby. Os pido disculpas queridos lectores, pero algunos problemas que encontré a la hora de trabajar con estas estructuras me obligaron a replantearme los métodos que estaba utilizando, así que hemos estado durante este último año aprendiendo otras técnicas que permitieran trabajar con el servidor de forma más eficiente. Esa es la buena noticia, continuaremos el ejemplo tal y donde los dejamos pero este, y siguientes artículos, estarán sustentados sobre una base de conocimiento mucho más sólida.

 

El campo clave

Nos planteábamos en el artículo anterior «Desarrollando con Microsoft Access para tablets – El acceso a los datos (2)» el tema más enrevesado que era la gestión del campo clave cuando no podíamos añadir el registro directamente a su tabla definitiva. La cuestión se resuelve, en vez de usando campos auto numéricos, generando una clave tan compleja que evite la posibilidad de que en el servidor, llegado el momento de enviarle el registro, no exista ya otro registro con la misma clave. Y es aquí donde debemos centrar nuestros esfuerzos.

Usando un número aleatorio

Una opción con la que estuve haciendo pruebas desde Microsoft Access antes de dejar a medias estos artículos fue la de crear un número aleatorio para mi campo clave. ¿Es una opción factible?, no lo es. Y no lo es porque nuestro amigo Murphy hará de las suyas para que tarde o temprano dos números aleatorios generados en distintas tabletas sean idénticos y nos genere un problema al insertarlos en la nube, así que esta opción terminé descartándola.

Definiendo una clave compleja

Descartando el numero aleatorio nos planteamos cómo podemos generar una clave única y difícil de repetir. Aquí os voy a dar una buena idea, pero no será la mejor, y seguramente tampoco la más efectiva, pero veréis que la solución es bastante ingeniosa y nos puede sacar del apuro. Además estoy convencido de que otros programadores de Access podrán aportar otros mecanismos que nos resuelvan este problema. Les animo a que nos ilustren al respecto.

Vayamos al lío, el planteamiento que os propongo es componer nuestra clave con los siguientes datos:

  • 4 cifras del año
  • 2 cifras del mes
  • 2 cifras del día
  • 2 cifras del minuto
  • 2 cifras del segundo
  • 2 últimas cifras de los mili segundos

Con esto seriamos capaces de generar una clave alfanumérica, para esto usaríamos un campo tipo texto, difícilmente repetible. Ya sería complicado que dos personas en el mismo instante creen dos registros en distintos equipos. Pero aún así, seguro que Murphy se las apañaría para hacerlo. Podemos darle una vuelta más de tuerca si al inicio de nuestra clave añadimos un código de usuario, del usuario que esté dando de alta el registro, por ejemplo su DNI o cualquier otra cosa que sea difícil de repetir como el id de cliente si lo tenemos a mano. Una clave creada de esta manera nos daría un texto más o menos así:

Clave única

Otro punto interesante de esta construcción es que de un vistazo al campo clave estaríamos viendo quién y cuándo ha creado el registro.

Sobre cómo podríamos componer esta clave sería algo así:

Me.CampoId = Me.DNI & Format(Now, «yyyymmddhhmmss» & Right(Format(Timer, «#0.00»), 2))

Con esto no deberíamos tener problemas a la hora de enviar el registro al servidor y que se encontrase con otro registro con el mismo Id.

Tipo de datos GUID

Por último dejaré este tipo de datos que incorpora Access para que el lector pueda informarse sobre ellos. Según Microsoft:

Identificador global único (GUID) de 16 bytes. Los identificadores GUID aleatoriamente creados son suficientemente largos de modo que no es probable que se superpongan. Se usan para diversas aplicaciones, como el seguimiento de mercancías.

En teoría, esto crearía un campo clave aleatorio lo suficientemente complejo como para que se pueda repetir. Es otra opción más a tener en cuenta y que podemos analizar en próximos artículos.

 

Referencias

Este artículo forma parte de una serie que pretende ilustrar como trabajar con datos alojados en un servidor cuando no siempre hay conexión al mismo. Puedes ver el resto de artículos en los siguientes enlaces:

Desarrollando con Microsoft Access para Tablets-El acceso a los datos (1)

Desarrollando con Microsoft Access para Tablets-El acceso a los datos (2)

 

3 comentarios

Responder a Antonio Jesús Moreno García Cancelar respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.