Visual Basic - Error al usar el programa en red

Hola: Necesito una ayuda mas que urgente.
Tengo un programa que corre muy bien en mi maquina pero lo instalé en una red y se cuelga, generando ademas enlentecimiento del servidor.
Uso en el programa solamente data combos asociados a un dbgrid.
Para acceder a los datos coloqué en el servidor el ejecutable y en el mismo directorio mi base acces.
Uso en el form load la instruccion ChDir App.Path para acceder a los datos.
Donde puede estar el problema ????? No configuré ninguna conexion al servidor es necesaria ? es muy complicada de hacer ?
Puede ser que el ejecutable deba estar en cada máquina y solo la base en el servidor ???? No creo que sea eso, me parece mas bien un tema de la manera de acceder a los datos, no se.
En las referencias la opcion Microsof DAO 3.6 object library está marcada.
Son mucha preguntas en una ?????
Es que estoy muy mal porque fueron tres meses de trabajo y ahora el programa no corre.
Espero su ayuda gracias

Hola Patry a ver si te ayudo un poco.

Primero ya estaria pasando a ADO.
Despues este tipo de programa se hace asi, la base puede estar en una carpeta del servidor compartida y tendrias un ejecutable en cada maquina el cual se conecta a la base mediante una coneccion propiedad conection String en ADO
Otro punto importante es el CursorLocation
dbOrigen.CursorLocation = adUseClient

asi que hay mucho por hacer
espero te haya servido, cualquier cosa escribime no hay drama.

Conection y CursorLocation no lo maneja el data control ??? tengo que manejarlo yo con código ?

Patricia, si no entiendes las explicaciones quizas debas plantearte que no estas preparada para esto. Conection y CursorLocation son propiedades que definen como trabajará ADO.

No hace falta cambiar de directorio para poder acceder a ningun archivo, sea una DB o cualquier otro tipo, con hacer referencia a app.path para indicar la ruta suficiente. Por ejemplo:

Data1.Database = App.Path & "\DB.mdb"

Me parece que el que no entiende sos vos. Yo a la base puedo acceder perfectamente pero al rato comienza a quedar lenta la conexion y el servidor se cuelga, y pregunté si el problema puede estar en que el ejecutable está en el servidor y lo corro con un acceso directo desde los clientes
Christian me respondió hablando de las propiedades conection y CursorLocation que yo no las nombré porque me parece que los data control ya se encargan de ello.
El programa corre perfecto si la base y el ejecutable estan en la maquina que lo corre. Si lo paso al servidor se enlentece y se cuelga. Por lo tanto mi pregunta era. Se soluciona el problema colocando el ejecutable en cada máquina o la solucion pasa por otro lado ?
Igor podrias poner mas esfuerzo en ser amable y no en querer dejar mal a los demas

El que el ejecutable esté en cada cliente tiene mucho de positivo. El uso de la memoria es más eficiente (cada instancia se ejecuta en un memoria única). El problema es que para la conexión deberías ocupar otra forma de localizar la base de datos, pero no es tanto problema, por que en lugar de usar App.Path sería algo como "\ServidrorCarpeta".
De cualquier forma, esto no garantizaría una mayor agilidad y tampoco que deje de funcionar el programa. La recomendación, para la segunda versión del programa es que utilices una manejador de base de datos gratuito.
Aquí nunca nos hemos puesto de acuerdo, mucho debido a que el amor es ciego y algunos viven enamorados de MySQL. Yo en lo particular recomendaría SQL Server 2005 EE, que es más cercano a Access y que te proveería de velocidad y funcionalidad mejorada. Calro, para esto tendrías que hacer caso a una de las recomendaciones que ya te han dado y acercarte a ADO.

Saludos.

Gracias pacopaz pero la idea no es hacer una segunda version del programa sino que este funcione.
La base de datos es muy pequeña las consultas son sumamente sencillas no deberia de haber un problema de lentitud por ser acces.
Hay otro problema que esta haciendo que la aplicacion y el servidor no se lleven bien. Voy a probar con colocar la aplicacion en los clientes y veremos que pasa.

La otra cosa que se me ocurre es que asegures que solo cuando necesites algo de la base de datos abras la conexión y cuando tengas lo que necesites, la cierres. En el caso de access esto produciría un lapso de tiempo para abrir y otro para cerrar, pero aseguras que la base de datos se ocupe sólo cuando se requiera. Esta es una práctica usual para todas las bases de datos. Si te parece que tarda demasiado, entonces abre una única vez, y cierra cuando abandones el programa. El problema con esto es la cantidad de conexiones abiertas y lo que esto puede significar: baja de rendimiento y posibles e innecesarios bloqueos de registros.
Otra, que las consultas tipo select * sean las menos posibles.
Y por último, tener una buena red, con un buen desempeño, que se supone debe ser lo primero a asegurar.

Saludos.

Lo tendré en cuenta pacopaz Gracias.
Con respecto a lo de abrir y cerrar la base eso es una de las cosas que yo había preguntado y no se en realidad. Yo no abro la base en ningun momento . No coloqué una sentencia OpenDatabase eso lo dejo en manos de los DataControl, esta mal eso? puede estar causando problemas? Si no voy a tener que quitar los Data y hacer todo con código.
Lo de la red tenés razon, el tema es que yo hice el programa pero con la red no tengo nada que ver de eso se encargan otras personas.
Gracias de nuevo

Respecto a usar DataControls te cuento que, al menos a nosotros, nos ocasionaron problemas en Windows Vista: aparecía un mensaje de error y no funcionaban; los quitamos todos y mejor usamos recordsets.