Access 2000 en red

Cierto es que Access es más un 'juguetito' que una base de datos seria, pero si tienes problemas de rendimiento con una base de datos de ese tamaño el problema no está en Access, sino en cómo lo manejas. Tengo en funcionamiento bases de datos de varios gigas en access funcionando hasta con 36 puestos, sin mayor problema que tenerlo muy clarito.
Volviendo al caso. Con lo que pones es muy insuficiente como para saber dónde está el problema, pero échale un vistazo a la consulta base del informe ese al que haces referencia. Fíjate en las relaciones que tienes en la consulta, y comprueba que no sean demasiado costosas. ¿Cómo? A ser posible deben utilizar relaciones (Herramientas/Relaciones), campos que sean índices de las tablas (a ser posible clave primaria) y debes evitar llamar a funciones en la consulta base del SQL.
Te puede ser de utilidad, si no lo has probado ya, el analizador (Herramientas/Analizar/Rendimiento) que quizá te diga algo.
Y como cosa que puedes probar, hazte una copia de la consulta base del informe como consulta a secas, sin el informe. Debe tardar en ejecutar más o menos lo mismo que el propio informe. Ahora ve quitando una tabla cada vez, empezando por las más triviales. Vas ejecutando, en un momento dado deberías notar que la velocidad cambia mucho. Fíjate entonces en qué estás haciendo con esa tabla que acabas de quitar, posiblemente eso te de alguna pista.
Bueno, ya me estoy enrollando mucho. Espero que todo esto te pueda dar alguna idea de por dónde tirar, si sigues teniendo problemas y puedes concretar un poco más, ya sabes

Primero, muchas gracias. Luego, quiero comentarte alguna cosilla, ¿nunca te ves forzado a realizar un informe que requiera añadirle funciones (a mí es que me piden cada cosa...)?
De todos modos, no creo que estén muy mal las consultas base de los informes. Me he fijado en que la velocidad que tardan en salir depende de los formularios que tenga abiertos. Supongo que si se le han pedido los registros a la base de datos "origen", luego le resulta más cómodo recuperarlos para cualquier informe o lo que sea. ¿Tú sabes algo de esto? ¿Y si se puede hacer algo con este tema que pueda mejorar el rendimiento de los informes y demás?
Una última cosa, ¿no te dan problemas bases de datos de varios gigas? ¿Te importaría darme algún ejemplo de cómo te lo montas?

... la verdad es que a veces no quedan más narices. Pero la mayoría de las veces, se pueden sacar las funciones de la consulta, y en su lugar obtener los campos necesarios para ejecutar esas funciones en el evento 'al dar formato' del informe. Lo que se gana es en la optimizaciones del SQL del Jet, vamos, que los cruces y obtenciones de datos se aceleran mucho.
Tema dos, en parte es cierto, pero sólo en parte. Depende de los bloqueos que se establezcan en la bdd como resultado de la compartición, pero en general, pues sí que los obtiene más rápido si los has accedido antes. No creo que sirva de mucho, pues de todas formas el cuello de botella sigue siendo que te tienes que traer todos los datos al puesto de trabajo para mostrar el informe.
Y en cuanto al tema tres, normalmente bases de datos de tamaños muy grandes suelen tener una gran cantidad de datos 'casi sólo de lectura' mientras que otros se actualizan casi constantemente. Un ejemplo claro es que los datos vayan por ejercicio, los ejercicios anteriores casi no se tocan mientras que en el ejercicio actual hay movimientos continuos.
Lo que suelo hacer en este caso es fragmentar la base de datos global en varios mdb, bdej1995 al bdef2003 p.ej, desde los puestos se vinculan todas, teniendo el nombre local del vínculo también distinto para cada ej. datos1995 apuntando a la tabla datos de \\servidor\carp\bdej1995 y así.
Cuando quiero lanzar consultas o informes sobre todos los registros, tengo una consulta de nombre datosTodos que es una union de todas las tablas.
¿Y qué se gana con todo esto? Básicamente estabilidad, no rendimiento, ya que los mdb cascan más cuanto más grandes sean, y sólo al ser escritos. Los más grandes pero menos escritos son los 'casi históricos', no cascan porque casi nunca hay escrituras simultáneas de varios puestos.
El más pequeño (a veces incluso he hecho versión mensual) es el más escrito y más delicado, pero precisamente porque lo mantengo en un tamaño limitado, no suele dar problemas. Aún así, me he permitido el lujo de sacar una copia cada media hora de ese mdb a un carpeta backup (es pequeño, se puede hacer). Muchas de estas copias no son válidas porque en el momento de sacarlas se estaban escribiendo datos, pero en ese caso tiro de la anterior... nunca he perdido más de dos horas de trabajo de la gente.
Uffff... filosofía del Access.. voy a trabajar un poco.
(Por cierto, si haces bases de datos de estos tamaños tienes que tener muuuuy claro el coste de los accesos, HAY que ir por indices. Si es necesario, haz una pequeña consulta que prefiltre de modo rápido los registros que 'podrían' ser necesarios, y sobre ella montas una consulta más lenta que obtenga el resultado final. Los criterios 'lentos' se ejecutarán menos veces')