¿Proyectos Access XP?

Te estás enfrentando a un problema típico por el que pasamos todos los desarrolladores.
Efectivamente, el migrar una aplicación actual hacia una plataforma cliente/servidor requiere de un buen análisis para no tener que volver a repetir el proceso en un tiempo relativamente corto.
Primero te menciono un error grave en el que has caído con lo que me dices: la forma como tienes tu BD actual NO ES UN ESQUEMA CLIENTE/SERVIDOR, ya que vincular unas tablas desde el servidor hacia los .MDE de los cliente lo único que hace es COMPARTIR la BD entre los usuarios ¿ya trataste de quitar los permisos de lectura de la carpeta del servidor? :-) ¿No se puede? :-( CLARO QUE NO, porque en realidad la BD sólo está compartida a los usuarios, lamento decirte que cualquier usuario se la puede llevar.
Toda la tecnología que mencionas es la típica que se usa para aplicaciones clientes/servidor, PERO por experiencia te digo: no te dejes envolver por tanta "palabrería informática" que popularmente hay en boca de los desarrolladores, esto más que ayudar a uno, sólo nos confunde. Hay que distinguir algunas cosas:
-Dreamweaver es una plataforma de desarrollo, no un lenguaje.
-ASP y PHP son scripts que te permiten enriquecer tus páginas html para hacerlas dinámicas.
-IIS y Apache son servidores web (IIS -> ASP, Apache -> PHP).
-VB te sirve para desarrollar aplicaciones ejecutables, VB Script te sirve para crear aplicaciones Web (en conjunto con ASP).
-Y por último, Access y SQL Server son bases de datos, con la diferencia que la última es la ÚNICA que te permite crear aplicaciones Cliente/Servidor.
Ahora sí, sabiendo estas pocas cosas ¿hacia dónde quieres ir? Esta respuesta depende mucho de ti y de tus necesidades informáticas, pero en lo personal, te podría dar algunos tips que EN MI CASO yo haría:
Primero, un esquema cliente/servidor te EXIGE que separes los datos y la aplicación (ya trataste de hacer eso con el .MDB y los .MDE, pero por ahí no va la cosa). Luego debes determinar cómo deben los usuarios acceder a la información: vía internet o dentro de la empresa. También debes decidir cómo van a instalar su aplicación: dándoles la facilidad de usar cualquier computadora en el mundo sin instalar nada (WEB) u obligándolos a instalar algo que, aunque es mínimo, deben hacerlo para poder acceder (proyecto de Access, Visual Basic).
Hay varias alternativas para las aplicaciones cliente/servidor:
- Usando páginas ASP con una BD de Access en el servidor Web.
- Usando páginas ASP con una BD de SQL Server en el servidor Web o en otro servidor.
- Usando un proyecto de Access que requiere configurarse en cada PC que acceda a los datos.
- Usando Visual Basic con una BD de SQL Server dentro de tu empresa.
En lo personal opino que los proyectos de Access son grandiosos, pero siempre existirá la necesidad de configurar "algo" en el equipo cliente para poder acceder a la información. Yo preferiría hacer mi proyecto cliente/servidor utilizando páginas Web (ASP), pero la selección de la BD (Access o SQL) dependerá de tus necesidades.
Sabes muy bien que un sitio Web les da a los usuarios "independencia de datos", ya que lo único que necesitarían para acceder a la aplicación es un Internet Explorer (o Netscape) sin necesidad de instalar nada (lo que tú deseas), y lo mejor de todo, pueden entrar desde cualquier lugar del mundo, porque lo que acceden en realidad es una página, no la BD de Access. Y esto también, por si fuera poco, no requiere de un servidor Web en internet, ya que también puede ser un servidor dentro de tu misma empresa y ahora sí, puedes proteger los datos TOTALMENTE del acceso indebido de los usuarios, ya que como dijimos sólo se accede a las páginas (y a los datos vía ODBC).
Debes tomar en cuenta que Access NO ES una base de datos para aplicaciones cliente/servidor. Nos da ese "efecto" cuando movemos nuestros datos (MDB) al servidor Web, ya que las páginas son las que acceden los datos y no lo usuarios. Si tu BD va a almacenar relativamente pocos datos, lo que te conviene es usar esta opción, ya que una de las ventajas es que no tendrás que pagar algún tipo de licencia (como es el caso de SQL).
PERO, cuando se decide hacer "en serio" un sistema cliente/servidor, la mejor opción es elegir SQL Server como base de datos. Revisa las ventajas de SQL Server en ésta página:
http://www.arsys.es/soporte/programacion/servbases.htm
Un punto más para tomar en cuenta en la migración desde Access hacia el Web es que tu aplicación no pasa "idéntica", por ejemplo, dices que tu aplicación tiene multimedia, y si acaso instalaste componentes activex y cosas raras que no puedes instalar en una página Web, eso causará que la aplicación no opere igual.
Como ves, hay muchos puntos para tomar en cuenta, pero mi recomendación principal es que necesitas documentarte rápidamente de esta tecnología (ASP, SQL Server) para evaluar y tomar una buena decisión.
Espero que esto te sirva como una "pequeña" guía.

Hola David:
Desde ya muchas gracias por tu opinión. Coincido en casi todo tu análisis. El que Access no sea cliente/servidor ya lo sabía es por ello entre otras cosas el fin de migrar para disminuir el tráfico en la red.
Respecto de ASP/SQL Server... es lo que pensé hace un tiempo, lo que cambié un poco fue al saber de que PHP se ejecuta en el servidor y no en el cliente.
Mi preocupación es el hecho de no dejar libre los scripts para que "nadie" pueda acceder, porque son aplicaciones comerciales y no quiero que me las copien tan fácilmente, ... sí ya sé que todo se puede piratear, pero.. que no sea tan fácil.
Coincido con lo de usar nada más que el explorador, esa es la idea, aparte de aislarte del tipo de plataforma elegido por el usuario.
Usar ASP parece lo "mejor" para mí porque el código de VBA es similar, pero los scripts van a estar disponibles en las máquinas de los usuarios.
De yapa quise instalar el trío Apache-PHP-MySQL, y resulta que no se que problemas tengo con el servidor y su configuración.
Decime que pensás respecto de los scripts del ASP, tema seguridad y esas cosas.
Desde ya, te agradezco tu valiosa opinión.
Espero tu opinión nuevamente.
Un abrazo.
Sergio

Honestamente sobre PHP no te puedo comentar nada ya que no lo utilizo, de ASP sí.
Hay algunos puntos en los que estás equivocado:
Las secuencias de comandos de ASP NO LAS VEN los usuarios, se ejecutan en el servidor al igual que PHP, es decir, el usuario nunca ve el código original de ASP, lo único que ve en su navegador es el resultado HTML del programa ASP. Lo que sí se puede ver (al igual que PHP) son los scripts que están en el servidor, y la gente que puede tener acceso a ellos son los administradores del servidor, los webmaster, etc. toda aquella gente que tenga que instalar las páginas en el servidor tendrá acceso al código fuente de ASP.
Existe una forma de codificar las instrucciones de ASP de forma que sean ilegibles para el usuario (incluso para los administradores), y es utilizando el "Script Encoder" de Microsoft (busca información al respecto en msdn. Microsoft.com). Pero, efectivamente como dices, existen "por ahí" algunos decodificadores que revierten el proceso y dejan visible nuevamente el código de ASP. Pero obviamente sólo usuarios experimentados serán hábiles para encontrar dichos decodificadores, lo que reduce las posibilidades de que tu aplicación sea hackeada.
Quien te diga que PHP no requiere codificarse te está mintiendo (visita esta página: http://www.rssoftlab.com/phpenc.php4), y sabes muy bien que cualquier cosa que se pueda codificar, también se puede DE-codificar, usar ASP o PHP es decisión tuya, pero sobre eso mi opinión es la siguiente:
Con ASP y VB script tendrás más ventaja y facilidad a la hora de migrar tu aplicación ya que, cómo dices, es muy similar a VB para aplicaciones (utilizada en Access). PHP tal vez pueda correr bajo Apache para Windows, pero tengo entendido que todavía tiene varios problemas de incompatibilidad, además de que nació con toda la intención de correr en plataforma LINUX (o UNIX), por lo que la COMPATIBILIDAD sería un punto que habría que analizar a fondo.
Aquí te doy el vínculo a una página que estoy seguro que cubrirá tus necesidades de seguridad de páginas Web: http://www.protware.com
En general, es lo único que te puedo aportar de mis conocimientos.