Sí. Sí hay que usar relaciones entre tablas antes de moverlas a Sharepoint

Javi Terán, a base de buenas prácticas, demuestra cómo se debe hacer la exportación a Sharepoint: http://javiteran.web.officelive.com/default.aspx

Después de un sabroso hilo en las news de Access, llega a la conclusión de que estableciendo todas las relaciones y con la pesataña de búsqueda completada, al mover toda la base de datos a la vez, se renumeran los índices pero también se actualizan en cascada las claves externas vinculadas.

Seguro que Javi pondrá un detallado artículo en su blog y fácil que yo haga algo más detallado en este mismo, pero ahora urgía poner esta nota para corregir mi anterior apunte en el que decía que había que borrar las relaciones.

Problemas al mover la aplicación a Sharepoint

Antes, yo tenía el problema de que no conseguía mover la base de datos entera y lo apañaba intentando hacerlo por partes, con la cantidad de problemas que eso me suponía. Precisamente para conseguir un escenario similar al de Javi, a base de intentos lo conseguí y tomé algunas notas:

- Si hay alguna tabla vinculada, parece que no se puede subir la aplicación

- Una tabla que se resistía a copiarse (y bloqueaba toda la subida) dejó de hacerlo cuando suprimí un campo de datos adjuntos. Sin embargo, después otras con datos adjuntos que contenían datos, subieron sin problema. La diferencia es que en la primera conteían música (varios megas cada adjunto) y en la segunda, la que subía sin problemas, sólo había unas pocas imágenes con poco peso.

- Una tabla que también se resistía no tenía datos adjuntos, ni nada raro en su estructura, pero eran unos 14.000 registros.

Parece que el peso de las tablas es un obstáculo importante a la hora de mover la aplicación de una vez a Office Live Small Business.

Elegir la aplicación

El primer ensayo fue del todo frustrante. Probé con una aplicación compleja, con datos no excesivos pero bastantantes, abundantes tablas, con uso profuso de subformularios, cuadros combinados, etc. y la subí de un tirón. Aquello no había manera de moverlo y, encima, los datos eran incoherentes. Estaba claro que se habían cambiado todos los campos clave, que faltaban índices y que había que replantear la aplicación buscando estrategias para disminuir el tráfico de red.

Los últimos ensayos los he realizado con una aplicación pequeñita, sencilla y con pocos registros y me ha ido mucho mejor. Suena a trampa usar una aplicación así, pero ese tipo de aplicación existe y es frecuente en Access, de hecho, la aplicación está en uso. Además, si queremos iniciarnos en albañilería de software, debemos empezar por reformar la cocina, no por el Escorial, ya tendremos tiempo, con un poco de experiencia, de ver el alcance de nuestras posibilidades.

Elimina las relaciones antes de subir las tablas

Algo que vas a perder definitivamente con Sharepoint son la integridad referencial y la eliminación en cascada, entonces ¿para qué queremos las relaciones? Sharepoint es "tan listo" que cuando ve una relación es capaz de crear un campo de búsqueda en la tabla que subimos, pero es "tan tonto" que sube una copia de la tabla de búsqueda por cada una de las tablas que tengan una relación a ella como clave externa. Cierto que cuando he comprobado este fallo ha sido subiendo las tablas una a una, porque me fallaba la opción de subirlas todas a la vez, pero con una vez que pase ya es suficiente para librarnos de las relaciones.

No es necesario subir todas las tablas

¿Qué pinta la tabla SwitchBoardItems en el servidor de Sharepoint? Lo mismo pasa con las provincias, meses... Otros datos, como los países, tipos de iva, etc. cambian de tarde en tarde, pero para eso podríamos tener un sistema de doble copia, en el servidor y en local ,y mantener una tabla de versiones que se comprobaría al iniciar la aplicación y copiaría a local los datos del servidor en caso de ser una versión distinta. De momento, como estamos en pruebas, dejemos esas tablas en local y ya encontraremos una solución más andelante, antes de que el mapamundi cambie de nuevo.

Tranquilo, no se pierden los valores de los campos clave

¡Aaarrrg! Has subido y vinculado tu tabla y compruebas con horror que tu campo IDMitabla ha sido sustituido por un simple ID renumerado desde cero, de manera que ya no coincide con tu numeración, que tenía sus huecos. Tus valores no aparecen por ningún lado  ¿Cómo vas a poder relacionar así? No hagas como hice yo, que el teclado no tiene la culpa para tratarlo así. ´

Abre la tabla vinculada, sitúate sobre la fila de nombres de campos y, con el botón derecho del ratón, selecciona "Mostrar columnas..." y elige el campo _ID, con guión bajo delante. Ahí están los datos originales. Sin indexar, pero ahí están.

Ahora toca la parte pesada: ir tabla por tabla, buscando qué claves externas hacen referencia a esa y cambiarle los datos. Podemos usar una serie de consultas de este tipo:

UPDATE LaOtraTabla LEFT JOIN Mitabla ON laOtraTabla.id_Mitabla = Mitabla.[_ID] SET LaOtraTabla.id_Mitabla = [Mitabla].[ID];

Seguramente, podremos hacernos unos procedimientos para evitar tener que ir diseñando la consulta tabla por tabla y clave externa por clave externa, pero, como se supone que estamos probando con una aplicación sencillita, de momento, no nos vamos a entretener en ello.

Añade índices a las listas

En Sharepoint no se va a notar mucho, pues vemos las listas planas, pero en Access vamos a relacionar unas tablas con otras y que los campos claves estén indizados se va a notar mucho en velocidad.

Los índices deben añadirse en el sitio Sharepoint, pero podemos ir al formulario de modificación directamente desde Access. Pinchando con el botón derecho del ratón sobre la tabla vinculada, podemos elegir "Opcione de Lista de Sharepoint" y ahí "Modificar columnas y configuración"

 Empieza a probar y no desesperes

Si todo parece salir bien a la primera, seguro que estás equivodo  

Ya nos iremos contando nuestras tribulaciones. 

 

13:11 GMT  |  Read comments(0)

20 March

Access 2007 y Office Live Small Business