• Viernes 8 de Noviembre de 2024, 16:33

Autor Tema:  Re: Metodos para Datanevironment  (Leído 1249 veces)

zambito

  • Miembro activo
  • **
  • Mensajes: 71
    • Ver Perfil
Re: Metodos para Datanevironment
« en: Viernes 26 de Septiembre de 2003, 21:18 »
0
Estoy tratando de reeescribir una aplicacion basada en ado con objetos visuales hacia datenvironment pero tengo problemas al tratar de usar los metodos en los objetos command
por ejemplo
Adodc1.recordset.movefirst
y con los dataenvironment no tengo clara la sintaxis...alguien me puede ayudar?
Puedo usar el metodo find? como?

Brroz

  • Miembro de PLATA
  • *****
  • Mensajes: 1058
    • Ver Perfil
Re: Metodos para Datanevironment
« Respuesta #1 en: Lunes 29 de Septiembre de 2003, 14:55 »
0
Hola zambito.

Te remito de nuevo a este tema http://foros.solocodigo.com/viewthread.php?tid=5078.

Ten en cuenta que no todos los command devuelven un recordset... luego es posible que si le aplicas las propiedades y métodos de un recordset te lleves una sorpresa. Si aún tienes dudas con el nº de Index, te recuerdo que es el orden del command (entre los que devuelven un recordset).

Suerte.

Brroz

  • Miembro de PLATA
  • *****
  • Mensajes: 1058
    • Ver Perfil
Re: Metodos para Datanevironment
« Respuesta #2 en: Lunes 29 de Septiembre de 2003, 14:58 »
0
Por cierto, tú que estás con ello:

¿Realmente merece la pena reescribir el código para utilizar un dataenvironment en lugar de implementar tú mismo los clásicos objetos?

A ver que nos cuentas.
Chao.

zambito

  • Miembro activo
  • **
  • Mensajes: 71
    • Ver Perfil
Re: Metodos para Datanevironment
« Respuesta #3 en: Lunes 29 de Septiembre de 2003, 20:15 »
0
cuando comence con visual basic y ado , lo q primero entendi y use fueron los objetos visuales, osea desde mi barra de herramientas colocaba los objetos ado en mi formularios y fuera...luego comence a leer sobre ado por codigo lo q me dio la nocion q se puede tener mas control sobre los objetos codificando todo pero...tampoco es necesario salvo en caso muy raros tener el control total sobre ado , hay cosas q hace muy bien por si mismo por ejemplo los bloqueos en red... ademas sobre todo me rehuso a usar codigo si hay formas mas abreviadas de usar ado, creo q es retroceder... cuando lo intente recorde mis tiempos programando en turbo pascal o algo asi...al final llegue a la conclusion de q lo q mejor me venia era una mixtura de objetos visuales y de codigo...osea ahi donde no llegaban los objetos visuales lo hacia por codigo y me ha ido bastante bien un par de problemitas con el metodo AddNew y algunos controles pero nada de importancia...Bueno me fui por las ramas...por ahi escuche datanevironment y me puse a experimentar haciendo un clon de una aplicacion pero tranformandola...te dire q al comienzo me deslumbro pero ahora creo q es mas de los mismo, osea eso mezcla de codigo con O.V....algunas ventajas solo manejas una sola conexion(algo q se puede hacer tambien con codigo) quizas un poco mas de velocidad(imperceptible en tablas pequeñas) y poco mas...bueno algo q me desanimo mas...he estado leyendo algo de VB.net y hasta donde he visto no incluye los famosos Data Environment...servira aprenderlos? tu mismo...
al proposito tu q usas?

Brroz

  • Miembro de PLATA
  • *****
  • Mensajes: 1058
    • Ver Perfil
Metodos para Datanevironment
« Respuesta #4 en: Martes 30 de Septiembre de 2003, 09:12 »
0
Hola zambito.

En algunos proyectos he utilizado OleDB/ODBC con ADO, en otros DAO (ya hace), y siempre implementando con código conexiones, comandos, etc. Para algunos casos muy puntuales controles data, casi siempre para tareas temporales.

Normalmente trabajo con bases de datos db/2 en iSeries (as400), para lo que uso mis propias clases creadas a partir de una biblioteca de tipos suministrada con el sofware para la conexión al  iSeries (client access) y la verdad es que funcionan bastante bien.

Ya ves que no utilizo dataenvironment, por lo que realmente no puedo hablar mucho de sus ventajas/desventajas, pero prefiero no cargar los proyectos con diseñadores y o.v. si puedo evitarlo.

Chao.