database - update - wp create post programmatically

Creando el Front End MDE

Question

Creé una base de datos para rastrear métricas, con algunos trucos de automatización (presentaciones de correo electrónico, .doc, .ppt, etc.) con una gran tabla principal y muchos formularios / GUI. Esta es la primera vez que me preocupo por un MDE / front-end para la cosa. Entonces, si usted es tan amable de responder algunas preguntas, o de ofrecer algún consejo, sería muy apreciado (no me gustaría que todo este trabajo no se utilice).

• ¿Qué es lo primero que necesito hacer? Es la versión 2000 que debe convertirse a 03 para crear el MDE, pero ¿se hace eso antes de usar el separador de base de datos?

• ¿La cantidad de objetos en la base de datos tendrá la capacidad de hacer esto? Tengo algo así como 80 formularios, 70 consultas, más de 20 macros, 12 tablas, etc. Pero, ¿la cantidad de objetos impide que algo de esto funcione bien una vez que la parte delantera está allí?

• cuando divido la base de datos, ¿puedo continuar trabajando / hacer cambios y tal en el "back-end", y hacer que esos cambios afecten directamente a la interfaz?

Estas pueden ser algunas preguntas básicas, pero no sé la respuesta, así que ... ¡Gracias!

Answer 1

Aquí está mi 2 ¢.

Pregunta 1 - Nunca he usado el divisor de bases de datos porque siento que tengo más control al hacerlo manualmente. Si lo haces manualmente, puedes hacerlo a una versión que no tenga un separador de base de datos. Pero si usa el divisor, entonces - sí - tendrá que actualizar a una versión que tenga un divisor antes de hacerlo.

Para hacerlo manualmente aquí están los pasos.

1. Respalda todo
2. Crea una copia de tu archivo en el mismo directorio. Entonces, si tiene un MyApp.MDB, cree una copia en el mismo directorio con un nombre nuevo, como MyAppDATA.mdb.
3. Abra el nuevo archivo DATA (MyAppDATA.mdb) y elimine todos los objetos EXCEPTO las TABLAS.
4. Abra el archivo de la aplicación (MyApp.mdb) y elimine todas las tablas.
5. También en MyApp.mdb ... vaya al menú Archivo / Obtener datos externos / tablas de enlaces para vincular las tablas en MyAppDATA.mdb a MyApp.mdb. Seleccione Todo y cree los enlaces.

Deberias hacer eso. Y si te equivocas hiciste una copia de seguridad ... ¿verdad?

Un par de consejos y trampas ... asegúrese de ir a Herramientas / Opciones y que NO está mostrando las tablas Sistema y Oculto. Simplemente no desea eliminar tablas del sistema de MyApp. Otra forma de hacerlo es NO borrar tablas que comiencen con MSys o USys.

Pregunta 2: no importa cuántos objetos tenga. De hecho, no tienes tantos objetos de todos modos.

Pregunta 3: Sí ... realizará cambios en el servidor en MyAppData.mdb y cuando abra MyApp.mdb esos cambios estarán automáticamente disponibles para ver y consultar en contra, etc. (En el diseñador de consultas puede que necesite guardar / cerrar / vuelva a abrir para ver nuevos campos si hizo el mod mientras estaba en la consulta). La EXCEPCIÓN a eso son las Nuevas Tablas. Deberá usar la opción Archivo / Obtener Datos Externos / Tablas de Enlace para crear enlaces a nuevas tablas.

Una cosa para recordar (y espero que ya se den cuenta) es que la única desventaja de dividir la base de datos es que cuando despliega el archivo frontal, la ruta relativa a los datos variará de una máquina a otra y no hay una automática volver a vincular las tablas en el acceso. Si sus clientes objetivo tienen acceso completo, siempre puede usar Herramientas / Utilidades de la base de datos / Administrador de tablas vinculadas para actualizar los enlaces a la ubicación correcta. Si no puede hacer eso, tendrá que hacer una de las siguientes cosas:
1. Escriba el código que hace el reenlace automático para usted. Básicamente comprobará los enlaces ... si no es válido, pedirá al usuario la ubicación de los datos (o lo buscará en un archivo INI) y volverá a vincular las tablas.
2. Despliegue siempre su aplicación en la misma ubicación en todas las máquinas. Si tiene visiones comerciales para su aplicación, esto no funcionará ... Lo menciono por razones académicas. Podría ser factible para una implementación limitada donde tienes mucho control sobre la ubicación de archivos en cada máquina.
3. Coloque el archivo de datos (MyAppDATA.mdb) en un recurso compartido de red y vincule la tabla a través de la red utilizando una asignación de unidad o UNC (/ miservidor / mydata / ApplicationData / MyAppData.mdb). Este último es preferido, pero ambos corren los mismos riesgos que el número dos.

Seth

PD: esta respuesta supone Access 2003.
PPS Si tiene visiones comerciales para su aplicación, la vinculación de la tabla debe ser REALMENTE robusta. PPPS Estoy de acuerdo con el comentarista en que es posible que desee dar el paso y hacer SQL si está en su conjunto de habilidades.

Answer 2

Esto sería un comentario a la respuesta de Seth, pero mi representante no es lo suficientemente alto como para comentar aún.

Seth hizo un gran trabajo respondiendo sus preguntas, solo quería agregar un poco más a la parte # 1 sobre el uso de Database Splitter. El divisor de bases de datos en el menú Herramientas funciona bien. Hacerlo manualmente también está bien, pero es mucho más rápido y fácil de usar el Splitter de base de datos. Lo he usado una docena de veces y nunca he tenido problemas después de usarlo.

http://www.databasedev.co.uk/split_a_database.html tiene una página decente sobre algunos de los pros, contras de dividir su base de datos.

http://www.accessmvp.com/TWickerath/articles/multiuser.htm también tiene buena información cuando se trata de una base de datos dividida en un entorno multiusuario.

Answer 3

Seth te dio una muy buena respuesta. Pero agregaré algunos comentarios.

La cantidad de objetos solo se vuelve relevante cuando te acercas a unos 1000 formularios, informes y módulos que tienen código. Hay un límite allí. Si obtiene ese mensaje cuando intenta hacer un MDE, es casi seguro que tenga un error de código y necesite compilar para encontrar el error.

Otro recurso es " dividir su aplicación en un extremo frontal y extremo posterior "

Consulte la página de descargas Auto FE Updater para que el proceso de distribución de nuevos FEs sea relativamente sencillo. La utilidad también es compatible con Terminal Server / Citrix bastante bien.

Answer 4

Una cosa que no se ha discutido, y esa es la cuestión de si la compilación de MDE podría fallar. Básicamente, si su código se compila en su MDB front-end, se convertirá en un MDE. Pero me he dado cuenta de que mucha gente nunca compila.

Algunos consejos para mantener su código de VBA en buena forma:

1. en las opciones de VBE, apague COMPILE ON DEMAND.

2. agregue el botón COMPILAR a su barra de herramientas VBE estándar y ÚSELO A MENUDO.

3. periódicamente, haga una copia de seguridad de su MDB y descompile / recompile.

Además, recuerde que debe conservar el origen de MDB, ya que el código de VBA no se puede editar en un MDE y no es recuperable por ningún buen método.

EDITAR:

Pasos para un descompilación:

1. haga una copia de seguridad de su MDB.

2. inicie una instancia de Access con el argumento / decompile commandline. Por ejemplo, tengo un atajo en mi escritorio que tiene esto como objetivo:

   "C: / Archivos de programa / Microsoft Office / OFFICE11 / MSACCESS.EXE" / decompile

3. habiendo abierto esa instancia de Access, abra el MDB que desea descompilar. Verás que nada sucede. NO HAGA NADA MÁS EN ESTA INSTANCIA DE ACCESO - cierre esta instancia de Acceso (la razón de esto es que Michael Kaplan, que sabe una o dos cosas al respecto, le recomendó que nunca haga ningún trabajo en una instancia de Access abierta con el interruptor de descompilación porque dijo que no había ninguna garantía de que el código de la aplicación Access se ejecutara en esas circunstancias de una manera que fuera completamente segura para todo tipo de trabajo de Access).

4. abra el MDB recién descompilado manteniendo presionada la tecla Mayús (desea asegurarse de que las rutinas de inicio no se ejecuten porque es probable que recompile el producto antes de que haya terminado la limpieza) y compacte el MDB (manteniendo presionada la tecla Mayús nuevamente )

5. abra el editor de código y compile el proyecto (DEBUG -> COMPILE [nombre de db] para aquellos que no tienen el paso 2 en mis instrucciones de compilación originales en la parte superior de la publicación antes de la edición).

6. Compacte el MDB (no importa si omite el inicio, ya que está completamente compilado).

¿Por qué tantos pasos?

Debido a que el propósito del descompilado es deshacerse del código p compilado para comenzar de nuevo desde el código canónico de VBA. Siguiendo los pasos anteriores, asegura que ha borrado completamente las páginas de datos que almacenan el código compilado antes de volver a compilar. La razón de esto es que sin el paso compacto después de la descompilación, en algunas circunstancias muy raras, el código puede comportarse de manera extraña. No puedo imaginarme que el viejo código-p descartado se esté utilizando de nuevo, pero hay algo acerca de los indicadores entre el código canónico y el código compilado que aparentemente no se enjuaga completamente con un descompilador sin un compacto.