Vengo de Vb6

"Lluís Franco" escribió en el mensaje
news:

:-)
Tiene gracia Leonardo,

Si bien hoy en día ya me desenvuelvo muy bien (creo) con .NET, creo que
será
muy difícil llegar a alcanzar el nivel de conocimientos que tenía con VB6.
Básicamente es una cuestión de envergadura, ya que si en VB6 podía decir
que
conocía un % muy elevado de todo lo que se podía (y NO se podía hacer),
así
como las limitaciones "by design" de la herramienta, con .NET hay
"demasiado" terreno para explorar.

Hola.

La "amplitud" del conocimiento no es una cosa que me preocupe: a mi edad me
sentiría incómodo presentando un examen de certificación :-). Creo que si me
pongo a evaluar cuanto sé sobre VB6 -con respecto al total del conocimiento
posible sobre el paquete basico, dejando de lado componentes y controles de
terceros- debo andar alrededor del 60%. Habiendo sido tres veces víctima del
"cambio mandatorio" (sin contar los porrazos de la juventud, como el paso de
los mainframe de IBM a los micros con Apple DOS o CP/M) sólo me preocupo por
aprender lo necesario para hacer lo que hago (claro que "lo que hago" puede
ser de lo más variado).

A veces me entero de que hay un nuevo "recurso", y lo examino un poco a ver
para qué me puede servir. Y casi nunca uno de esos nuevos recursos ofrece
suficiente funcionalidad o un potencial de cambio cualitativo que justifique
el esfuerzo de aprenederlo.

Lo que si me interesa radicalmente son los aspectos de metodo y los recursos
constructivos que ofrecen las herramientas, y en ese sentido ya VB6 me da un
poco de "asco" si lo comparo con VB.NET.

Salud!

"Leonardo Azpurua [mvp vb]" escribió:

Los objetos Dataset y DataAdapter son objetos de ADO.NET (creo). Una vez
has comprendido como usarlos, basta con que agregues Connection y Command
(conceptualmente parecidísimos a sus "ancestros" en ADO con A de ActiveX
¿tienes idea de qué puede significar la "A" de ADO.NET?), para poder
comenzar a usar ADO.NET.

Hola, Leonardo:

Con respecto a la pregunta que me haces, pues no tengo ni puñetera idea de
lo que puede significar la letra "A" de ADO .NET. Me imagino que significará
«ActiveX», porque a mi entender, lo único que hicieron con la "antigua"
biblioteca de ADO fue mejorarla extraordinariamente, y adaptarla para su
inclusión en el marco de trabajo de .NET, porque es sabido que ADO tiene sus
límites (el más destacado es que se basa en COM, y por tanto solo se puede
utilizar en plataformas Windows) , y había que hacer algunos cambios
importantes en su arquitectura para superar sus propias limitaciones, y
adaptarlo, repito, para que cumpliera con las especificaciones del marco de
trabajo de .NET, es decir, con el .NET Framework.

No hace falta que creas que los objetos DataSet y DataAdpater pertenecen a
ADO .NET, porque así es, dado que supuso pasar del concepto de «conjunto de
registros» (Recordset) al concepto de «conjunto de datos» (DataSet), que
actúa como si fuera una base de datos residente en el lado cliente, y por
tanto, desconectada del origen de datos, necesitando de un objeto que
hiciera de enlace entre el origen de datos y el conjunto de datos: el objeto
DataAdapter.

Me conoces y sabes que soy un defensor a ultranza de la utilización de la
biblioteca de ADO en contraposición con la obsoleta biblioteca de DAO, en
las aplicaciones de bases de datos con Visual Basic clásico. Pero
igualmente, desde que conocí el nuevo modelo de objetos que ofrecía ADO
.NET, me dí cuenta rápidamente de las inmensas posibilidades que dicho
modelo ponía en manos de los programadores de bases de datos, y ante una
aplicación desarrollada con VB .NET, por supuesto que utilizaré ADO .NET en
lugar del ADO clásico, cosa que nunca me cansaré de recomendar. Podíamos
decir que ADO fue bonito mientras duró. :-)

Sin desmerecer tu aporte (cuyo valor intrinseco es indiscutible) creo que
su utilidad es evidente para interactuar con un recordset de ADO desde una
aplicacion en .NET, pero los objetos con los que llenas el Grid son
objetos de ADO.NET.

Por supuesto, y así se lo hice saber a Mariano, dado que los ingenieros de
Microsoft ofrecieron la posibilidad para que el método «Fill» de un
adaptador de datos (objeto éste de ADO .NET), puediera tomar como argumento
un objeto Recordset de la clásica biblioteca de ADO, y poder disponer de un
objeto DataSet, y a su vez de un objeto DataTable, que mirándolo bien, hasta
nos podía servir para manipular los datos en el control DataGrid, y enviar
los mismos a una fuente de datos distinta, que es la gran ventaja del objeto
DataSet, que como bien sabes, actúa completamente desconectado de un origen
de datos concreto, cosa ésta última, y lo comento de paso, también se podía
hacer (o mejor dicho, se hace) con lo que se conoce como trabajar con un
objeto «Recordset desconectado» de la biblioteca de ADO.

En términos bizantinos, es la aproximacion mejor argumentada a la cantidad
de angeles que caben en la cabeza de un alfiler. En la practica, no veo
uso para semejante construcción salvo en el caso de que un componente
externo nos devuelva un Recordset de ADO, componente que a su vez tendría
serios problemas para justificar su existencia.

¡Hombre! Antes te he comentado una posibilidad para su utilización; ignoro
para qué otra cuestión más se puede justificar su utilización.

Y ahora te preguntó yo a tí una cosa. ¿Cómo compactarías una base de datos
Access utilizando únicamente objetos de ADO .NET? No me vayas a responder
diciéndome que la compacte desde el propio Microsoft Access, porque te diré
que el cliente no dispone de dicha aplicación. Yo, hasta que alguien me
explique otro método mejor, sigo compactando la base de datos con la
biblioteca JRO, que es un componente COM basado en la biblioteca de ADO, y
por supuesto, la utilizo mediante la Interoperabilidad COM que nos ofrece el
marco de trabajo de .NET. :-)

¡Salud!

Enrique Martínez
[MS MVP - VB]

Nota informativa: La información contenida en este mensaje, así como el
código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin
garantías de ninguna clase, y no otorga derecho alguno. Usted asume
cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o
sugerido en el presente mensaje.

"SoftJaén" escribió en el mensaje
news:

Y ahora te preguntó yo a tí una cosa. ¿Cómo compactarías una base de datos
Access utilizando únicamente objetos de ADO .NET? No me vayas a responder
diciéndome que la compacte desde el propio Microsoft Access, porque te
diré
que el cliente no dispone de dicha aplicación. Yo, hasta que alguien me
explique otro método mejor, sigo compactando la base de datos con la
biblioteca JRO, que es un componente COM basado en la biblioteca de ADO, y
por supuesto, la utilizo mediante la Interoperabilidad COM que nos ofrece
el
marco de trabajo de .NET. :-)

A lo cual yo, bizantinamente, escurro el bulto: el único componente donde
uso CyR todavía esta en DAO :-)))

Salud!