Autor Tema: Re: Pro y Contras de usar un DataEnvironment (Leído 3106 veces)

chiaravel · « **en:** Martes 8 de Julio de 2003, 14:17 »

Me gustaria de la ayuda y la opinion de los mas experimentados acerca de las ventajas y las desventajas de manejar las bases de datos en mi aplicacion usando un DataEnvironment.

Muchas Gracias

JackRandall

Para mi gusto el DataEnvironment no es buenao, ya que al instalar tu aplicaicon en otro PC pueden cambiar las rutas de la base de datos, asi que yo utilizo ADO y las bases de datos ke manejo con access 97 y 2000 y las de mysql, estas ultimas con una libreria llamada MyVBQL que me permite no utilizar el latoso DataEnvironment

J.M.Movilla

Yo, por contra, no puedo sino opinar en favor del uso del DataEnvironment, aunque sólo sea por la comodidad de diseñar los comandos, las SQLs con asistentes, las pruebas de conexión... y sobre todo porque en todo momento tienes a la vista la estructura de tus DBs, las tablas de cada DB, los campos de cada tabla... Vamos, que da gusto...

Respecto al problema que plantea JackRandall, eso te pasaría lo mismo si empleases AdocDc... Lo que hay que hacer es definir con código la ubicación de las DBs... Yo siempre tengo un fichero de Setup, en el que consta tal dato, lo paso a una variable pública (cPathData) y en el código indico el Data Source = cPathData & Nombre de la Base de Datos. Como sólo tienes que indicarlo una vez. al iniciar el programa... no creo que pueda considerarse un inconveniente.

A muchos sé que les gusta trabajar directamente por código, e incluso los hay que encuentran gustoso el manejar los AdocDcs... Como sabes sobre gustos no hay nada escrito. Lo que sí está claro es que ¡ADO y siempre ADO!!! Sin que se sientan ofendidos los partidarios de DAO..., por favor.

Y como ves, amigo Pablo, en mis respuestas últimas casi, casi obligo a los consultores a que den respuesta a mis participaciones. Veremos si conseguimos que nos hagamos todos más sensibles a la necesidad de "rematar" todas las cuestiones, por el bien de futuros consultores y también por educación.

HurryCrack

Hola colegas, yo soy de la opinion de ke el codigo lo controlo yo. No utilizo NUNCA objetos para as bases de datos, ni Data Enviroment, ni ADODC, ni Data para DAO ni nada absolutamente nada, simplemente lo referencio y a currar, lo malo es ke me pego unos curros de escribir codigo ke te pasas, pero modularizando simplemente los reutilizo, la ventaja es ke se exactamente donde y por ke puede fallar una conexion en un momento determinado. Un saludo

chiaravel

Muchas Gracias a los 2, a HurryCrack y al amigo Jose Maria.

En mi opinion (ya que esta pregunta fue hecha hace 1 mes Aprox), y por estar actualmente usandolos...

Los dataEnvironment son barbaros !!, obviamente quizas sea mas rapido en ejecucion el uso exclusivo de CODIGO, pero son muchas las ventajas de los DataEnvironment , en cuanto a la rapides de diseno y la visualizacion de toda la conexion a las BD.

En cuanto a la generalizacion de que todos los objetos son malos, con respecto al codigo, creo que existe una avismal diferencia entre un ADODC y un DataEnvironment, ya que por cada conexion habria que crear un ADODC, mientras que con un solo DataEnvironment se puede tener multiples conexiones.

En cuanto a la ruta de las BD, ese no es mi problema ya que mis BD estan siempre en el mismo lugar.

Gracias nuevamente a los 2.

J.M.Movilla

El tener los datos en una carpeta distinta a la carpeta de la aplicación es lógicamente opcional y a gusto del programador; pero cuando trabajamos en red... entonces no queda más remedio que definir dónde están las bases de datos...

Yo lo tengo resuelto así: Cada usuario tiene una carpeta desde la que arranca la aplicación. En esa carpeta tiene un fichero (Setup.mdb, por ejemplo) con una tabla en la que tiene su identificación, su clave de acceso encriptada y la ruta de las bases de datos (con el formato de dirección que más interese: HostMis datos, por ejemplo) amén de otros parámetros que me puedan interesar.

Al iniciar el programa abro ese fichero (que al estar en la carpeta de la aplicación no va crear problemas) y si el usuario introduce su password que coincida con la que consta encriptada en ese fichero, defino la variable "cPath" con el contenido del campo de la ruta en Setup... y de ese modo cada usuario tiene el acceso personificado, pudiendo modificar la ubicación del servidor siempre que queramos. Cuando un usuario detecte que no se encuentra la db en su sitio, se abre el control de abrir ficheros y copia la nueva ruta en su campo para que funcione bien en el futuro...

Seguro que otros tienen resuelto el problema con un fichero.INI... y yo le diría que enhorabuena, pero que no me cambio, porque lo mío a mí personalmente me va de coña marinera...

Y lo del DataEnvironment... seré un pesado, pero si te habitúas a él... (y te lo digo a tí, Víctor, de forma directa) verás que merece la pena soportar sus posibles inconvenientes...

Saludos a todos