Abrir archivo .accdr desde otra aplicaccion en access
Tengo un aplicativo con extensión .accdr, desde ahí verifico si se cumple una condición y si no lo hace debe abrir informes. Accdr... Utilicé "Application.FollowHyperlink Ruta", pero me dispara dos mensajes de seguridad y ya configuré todo el centro de confianza y siguen apareciendo.
Como nota adicional, ya usé Call Shell("C:\Program Files (x86)\Microsoft Office\OFFICE14\MSACCESS.EXE C:\CLU\DB3.MDB", vbMaximizedFocus), pero genera error
¿Hay otro método para abrir ese tipo de archivos o Call Shell está mal definido?
1 respuesta
Desde Access se puede obtener información de otra base de datos sin necesidad de abrirla, evaluar lo que se tenga que evaluar y tras ello tomar las oportunas decisiones.
El 'centro de confianza' es tan sencillo como informarle al sistema operativo de que tal o cual carpeta (y si es el caso subcarpetas) están autorizadas, a mayores se le puede indicar el tipo de permiso (permitir macros y demás), hay una utilidad que se creó en su momento en otro foro 'SeguridadAccess2010.exe' (si mal no recuerdo está diseñada en VBA6) que permite generar el entorno a la medida de la necesidad
Pero ... ¿se le indico lo mismo al antivirus?... es muy probable que sea el antivirus el responsable de esa 'falta de confianza', si es factible, bastaría desconectar de la red al equipo y ya sin enlace al resto del mundo, desconectar el antivirus y verificar que ocurre.
Como alternativa, hacer el control en un equipo que no tenga antivirus (o con el antivirus base de Microsoft, que tiene una comunicación más fluida con el sistema operativo).
A ver le explico... Tengo un aplicativo que hace las veces de actualizador del aplicativo principal... cuando el actualizador inicia, verifica en dos tablas, si el aplicativo principal está actualizado o no, sino está actualizado, copia y reemplaza el archivo y se cierra, pero si está actualizado, debe abrir el el aplicativo principal... Ese es el problema, que saca esos dos mensajes y los usuarios son flojitos para leer y me van a estar llamando porque creen que es un error
No veo una solución universal para esa funcionalidad, cada maquina suele estar adaptada al usuario (y los hay de todos los colores) por lo que pueden tener diferentes esquemas de seguridad.
Personalmente utilizaría otro procedimiento para acordar con el usuario el mantenimiento, a lo sumo aceptaría que las actualizaciones fueran de diferentes niveles
Las habrá estéticas (cambiar colores o posicionamiento de los menús ... ) pero sin ellas se puede seguir trabajando.
Las habrá funcionales (un cambio en las tablas, consultas o ...) y esas pueden crear conflictos si no se aplican.
El método:
Al abrir la aplicación de trabajo hace sus controles y 'detecta' que hay una nueva versión.
.- No la hay, simplemente inicia la jornada.
.- La hay, pueden darse que sea prioritaria (funcional) o simplemente no trascendente (estética).
-- Caso estético: se le informa al usuario que hay cambios y se le permite continuar (lo hará en otro momento, ahora puede estar apurado).
-- Caso Funcional: Se le informa al usuario que mientras no se actualice no podrá seguir trabajando y cierra la aplicación.
En cualquiera de los casos para actualizar la aplicación tiene que salir de la actual y tras ello iniciar el actualizador (que es independiente) y tras verificar que la principal no está abierta y que se cumplen las condiciones: la actualiza.
¿Qué puede pasar si un usuario inicia el actualizador porque tiene un rato disponible?:
Pues que evalúa si hace falta (y la aplica de darse las condiciones) o informa de que no hay nada que actualizar y se cierra.
Bajo mi punto de vista no habrá usuario que pueda poner problemas y lo que puede entrar en discusión es si actualiza siempre o no o ... pero eso es una directiva que la impone el programador o la consensua con el usuario, el programador solo es responsable de que la actualización no interrumpa el flujo normal de trabajo.
