Esto es para dar un pequeño fondo histórico e información de este switch de línea de comando no documentado en msaccess.exe. Para usarlo, solo corre: msaccess /decompile Y esto es todo. Pero, ¿Qué es exactamente lo que hace???? VBA Y LOS 11 ESTADOS DE COMPILACION Es correcto, internamente hay 11 niveles diferentes de compilación entre decompilar y compilar completamente como encontrarías en un MDE. Como vayas ensuciando objetos, decompilarás el proyecto, pero por ejemplo ensuciando a el Módulo 1 no removerá toda la información "compilada" sobre Módulo 2 ó Forma 1. Los niveles exactos son imposibles de detectar al menos de que tengas símbolos de fuente y corrección de errores (debugging) para VBA, y verdaderamente difícil sería aún entonces.... así es que dejémoslo como se lee, de que la pregunta de si/no de ¿Está compilado? tiene muchas subcategorías bajo la respuesta NO que escencialmente significa que no está compilado pero que algunas partes de el como que si lo están. CODIGO-P CONTRA TEXTO CANONICO Tú código se almacena en dos formas, cada uno de los cuales es un objeto de corriente (Stream Object) en el almacenamiento(s) del proyecto. Una forma es el texto canónico el cual ves y editas; el otro es la versión compilada del código que se corre. VBA debe siempre de compilar antes de correr, así es que en una aplicación que corre siempre encontrarás código-P. Y al menos que estés corriendo en MDE (donde la forma canónica se despedaza) siempre tendrás también la forma canónica. Cada vez que VBA piensa que el código compilado es inválido (como cuando haces cambios ó cambia el formato binario, lo cual pasa por lo regular en ciclos betas), "decompilará" el módulo y luego compilará nuevamente desde el texto canónico. BETAS DE ACCESS: FORMATOS BINARIOS, ETC. Las personas que estuvieron en las betas para Access 95, 97, y/ó 2000 recordarán los temas de formatos binarios. De estructura a estructura, los cambios se harían en VBA o en el OM de Access lo cual haría inválido al código ya compilado. Usualmente que se estrelle es lo mejor que puedes esperar. Para ayudar a resolver esto, se ha hecho algo de trabajo para tener una forma global de descompilar *TODO* el código que está presente en un proyecto para que no te arriesgues a tener ningún código inválido que a lo mejor se estelle. ********** Esta es la única razón por la cual está esta bandera aquí. El switch de línea de comando no está documentado porque nunca ha habido un cambio de formato binario excepto durante betas y dentro de estructuras internas... así es que no hay ninguna razón para documentar algo que nunca fue la intención usar. ********** AHORA hay algunos beneficios que son efectos secundarios de los cuales la gente ha hecho uso: 1) EFECTO SECUNDARIO: PROYECTOS CORROMPIDOS Ahora como efecto secundario, ¡tienes una manera de lidear con proyectos corrompidos! Verás, el texto canónico nunca es lo que está corrompido, siempre es una porción compilada del proyecto, como un módulo o más comúnmente el tipo de información de una forma ó reporte. Diciéndole globalmente a Access que la porción compilada debe de ser tirada a la basura, te deshaces de cualesquier pieza de código que sea la mala. Ahora este tipo de arreglo es lo que se habría hecho cargo del viejo defecto de páginas vba232 de Access93 y otros problemas donde Access caminaba al final de una vtabla y se estrellaba, así como un sin fin de pequeños problemas más. Esto es lo que hizo a PSS exponer primero esta bandera...si un proyecto está corrompido, esta es la mejor manera de descorromperlo. 2) EFECTO SECUNDARIO: TAMAÑO DEL PROYECTO Se encontró que hay momentos en los que un objeto será descompilado y mientras el objeto de corriente (Stream Object) del almacenamiento sería propiamente invalidado; sería huérfano y sería dejado en el Almacenamiento, y luego no sería limpiado posteriormente. Hay muchas aplicaciones que utilizan almacenamiento estructurado que tienen tales problemas en su colección de basura... VBA/Access es solo uno de ellos, eso es todo. A través del tiempo, estas corrientes huérfanas contribuirán a alguna hinchazón del proyecto. La gente nota que una aplicación totalmente compilada ocuparía más espacio que la misma aplicación totalmente compilada con todos los objetos importados a una nueva base de datos..... ese es precisamente el principal tema discutido aquí. Como habrás adivinado, el switch de /decompile (descompilar), el cual invalida *todas* las corrientes que contengan código compilado, hace un trabajo muy efectivo de recolección de basura y remueve estas corrientes huérfanas. Así pues /decompile (descompilar) /compact (compacta) harán a una base de datos del tamaño más pequeño posible. RIESGOS PARA DESCOMPILAR: PORQUE NO DEBES DE USARLO CONSTANTEMENTE Si piensas en el mecanismo, siempre te estás apoyando en que el texto canónico sea completamente válido, y te estás apoyando en la habilidad de invalidar completamente un estado de compilación. Si llegase a haber un problema en cualquiera de las áreas, /decompile (descompilar) tomará un proyecto que estaba trabajando bien y lo convertirá en queso cottage. Y mientras tales errores no debieran ocurrir....... es imposible hacer que la falla de /decompile (descompilar) surga sin usar /decompile (descompilar). Simplemente no probaron extensivamente un switch de comando de línea que nunca se quizo que se usara.... ni tenían porque hacerlo, en realidad. ASI ES QUE, POR FAVOR RECUERDA que es una técnica muy poderosa que fue agregada por razones que no tienen nada que ver con las razones que puedas tener para usarlo ahora. Puede ayudarte a salvar por otra parte a proyectos corrompidos sin esperanza. Pero úsalo de vez en cuando ya que puedes terminar en una situación peor que con la que empezaste, usando el switch globalmente en proyectos que no lo necesitaban. SI NO ESTA ROTO, NO LO ARREGLES.