Problema al abrir conexión activa con ADOX

"xavendano" escribió:

En mi app, ciertamente estoy utilizando ambas referencias ADODB y ADOX,
con una acceso al objeto de datos y puedo ejecutar mi intrucción .Open sin
problemas, y con la otra puedo manipular las estructuras que tendrá esa
base de datos. Hasta aquí todo sin problemas.

Si sólo usas ADOX para manipular la estructura de una base de datos
Microsoft Accesss, lo mismo te podría interesar utilizar un objeto
OleDbCommand, correspondiente al espacio de nombres System.Data.OleDb, para
ejecutar consultas SQL del Lenguaje de Definición de Datos (DDL) del motor
Microsoft Jet. Con dichas consultas puedes crear y modificar tablas, campos,
índices, y en definitiva, casi todo lo que se puede hacer con la biblioteca
de ADOX.

Utilizar el espacio de nombres System.Data.OleDb evitaría tener que hacer
referencia a las bibliotecas de ADO y ADOX, mediante la interoperabilidad
COM de .NET, lo que no significa que en el sistema del usuario final de tu
aplicación no haya que instalar los Componentes de Acceso a Datos de
Microsoft (MDAC), tal y como indicaré posteriormente.

El problema se presenta al momento de instalar dicha aplicación en un
cliente. Realizo la instalación con un proyecto del tipo Setup con
VS2005 para desktop, que funciona perfectamente salvo por el hecho
que me presenta un error al instanciar las librerías de ADODB. El error
es algo asi como como que no existen o no se pueden encontrar los
ensamblados de ADODB. Intenté luego instalar la versión 2.7 o 2.8
del MDAC_TYP pero fue un intento fallido, el problema persiste.

Con independencia o no que tu aplicación haga uso de las biblioteca ADODB y
ADOX, digamos que es requisito imprescindible instalar la versión 2.6 o
superior de los Componentes de Acceso a Datos de Microsoft, porque tales
componentes son requeridos si en nuestro proyecto de Visual Basic .net
utilizamos el espacio de nombres System.Data.OleDb o System.Data.SqlClient,
por tanto, si dices que has ejecutado el archivo redistribuible
MDAC_TYP.exe, entiendo que en el equipo cliente se han instalado
correctamente los Componentes de Acceso a Datos de Microsoft.

Ahora bien, como dichas bibliotecas se utilizan mediante la
interoperabilidad COM que nos dispensa el marco de trabajo de .net, deberás
de procurar que en la carpeta donde se encuentra el ejecutable de tu
aplicación, se encuentren igualmente los archivos correspondientes a los
ensamblados de importación de las mencionadas bibliotecas, es decir, que en
la carpeta deberán de existir los siguientes archivos:

Interop.ADODB.dll
Interop.ADOX.dll

Si no se encuentran dichos archivos, obtendrás una excepción en tiempo de
ejecución, con un mensaje más o menos parecido al siguiente:

[...] No se puede cargar el archivo o ensamblado
'Interop.ADOX.Version=2.8.0.0, ni una de sus dependencias. El sistema
no puede hallar el archivo especificado.[...]

Por tanto, en el archivo de distribución de tu aplicación deberás de incluir
los mencionados ensamblados de importación, los cuales los podrás encontrar
en la carpeta Debug o Release de tu proyecto, porque me imagino que se
habrán creado automáticamente. :-)

Despierta mi curiosidad el por qué el setup no "empaqueta" tambien las
referencias de ADODB asi como cualquier otra referencia o componente sin
problema

Ahí ya no llego. Desconozco el motivo por el cual dichos archivos no se
incluyen automáticamente en el archivo de instalación, pero eso no quita que
tú los añadas manualmente al proyecto de instalación.

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.

Esto es lo que uno llamaba en la universidad "Una clase magitral"

Excelente la información que acabas de enviar SoftJaen...

Muchísimas gracias!!!!!!


"SoftJaén" wrote in message
news:

"xavendano" escribió:

En mi app, ciertamente estoy utilizando ambas referencias ADODB y ADOX,
con una acceso al objeto de datos y puedo ejecutar mi intrucción .Open
sin
problemas, y con la otra puedo manipular las estructuras que tendrá esa
base de datos. Hasta aquí todo sin problemas.

Si sólo usas ADOX para manipular la estructura de una base de datos
Microsoft Accesss, lo mismo te podría interesar utilizar un objeto
OleDbCommand, correspondiente al espacio de nombres System.Data.OleDb,
para
ejecutar consultas SQL del Lenguaje de Definición de Datos (DDL) del motor
Microsoft Jet. Con dichas consultas puedes crear y modificar tablas,
campos,
índices, y en definitiva, casi todo lo que se puede hacer con la
biblioteca
de ADOX.

Utilizar el espacio de nombres System.Data.OleDb evitaría tener que hacer
referencia a las bibliotecas de ADO y ADOX, mediante la interoperabilidad
COM de .NET, lo que no significa que en el sistema del usuario final de tu
aplicación no haya que instalar los Componentes de Acceso a Datos de
Microsoft (MDAC), tal y como indicaré posteriormente.

El problema se presenta al momento de instalar dicha aplicación en un
cliente. Realizo la instalación con un proyecto del tipo Setup con
VS2005 para desktop, que funciona perfectamente salvo por el hecho
que me presenta un error al instanciar las librerías de ADODB. El error
es algo asi como como que no existen o no se pueden encontrar los
ensamblados de ADODB. Intenté luego instalar la versión 2.7 o 2.8
del MDAC_TYP pero fue un intento fallido, el problema persiste.

Con independencia o no que tu aplicación haga uso de las biblioteca ADODB
y
ADOX, digamos que es requisito imprescindible instalar la versión 2.6 o
superior de los Componentes de Acceso a Datos de Microsoft, porque tales
componentes son requeridos si en nuestro proyecto de Visual Basic .net
utilizamos el espacio de nombres System.Data.OleDb o
System.Data.SqlClient,
por tanto, si dices que has ejecutado el archivo redistribuible
MDAC_TYP.exe, entiendo que en el equipo cliente se han instalado
correctamente los Componentes de Acceso a Datos de Microsoft.

Ahora bien, como dichas bibliotecas se utilizan mediante la
interoperabilidad COM que nos dispensa el marco de trabajo de .net,
deberás
de procurar que en la carpeta donde se encuentra el ejecutable de tu
aplicación, se encuentren igualmente los archivos correspondientes a los
ensamblados de importación de las mencionadas bibliotecas, es decir, que
en
la carpeta deberán de existir los siguientes archivos:

Interop.ADODB.dll
Interop.ADOX.dll

Si no se encuentran dichos archivos, obtendrás una excepción en tiempo de
ejecución, con un mensaje más o menos parecido al siguiente:

[...] No se puede cargar el archivo o ensamblado
'Interop.ADOX.Version=2.8.0.0, ni una de sus dependencias. El sistema
no puede hallar el archivo especificado.[...]

Por tanto, en el archivo de distribución de tu aplicación deberás de
incluir
los mencionados ensamblados de importación, los cuales los podrás
encontrar
en la carpeta Debug o Release de tu proyecto, porque me imagino que se
habrán creado automáticamente. :-)

Despierta mi curiosidad el por qué el setup no "empaqueta" tambien las
referencias de ADODB asi como cualquier otra referencia o componente sin
problema

Ahí ya no llego. Desconozco el motivo por el cual dichos archivos no se
incluyen automáticamente en el archivo de instalación, pero eso no quita
que
tú los añadas manualmente al proyecto de instalación.

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.

SotJaen

¿Que pasa si algunos de los Dlls no existe? A pesar que tiene la copia
local en TRUE de su referencia.

Me refiero particularmente al caso de: Interop.ADODB.dll

De antemano, gracias...



"xavendano" wrote in message
news:

Esto es lo que uno llamaba en la universidad "Una clase magitral"

Excelente la información que acabas de enviar SoftJaen...

Muchísimas gracias!!!!!!


"SoftJaén" wrote in message
news:

"xavendano" escribió:

En mi app, ciertamente estoy utilizando ambas referencias ADODB y ADOX,
con una acceso al objeto de datos y puedo ejecutar mi intrucción .Open
sin
problemas, y con la otra puedo manipular las estructuras que tendrá esa
base de datos. Hasta aquí todo sin problemas.

Si sólo usas ADOX para manipular la estructura de una base de datos
Microsoft Accesss, lo mismo te podría interesar utilizar un objeto
OleDbCommand, correspondiente al espacio de nombres System.Data.OleDb,
para
ejecutar consultas SQL del Lenguaje de Definición de Datos (DDL) del
motor
Microsoft Jet. Con dichas consultas puedes crear y modificar tablas,
campos,
índices, y en definitiva, casi todo lo que se puede hacer con la
biblioteca
de ADOX.

Utilizar el espacio de nombres System.Data.OleDb evitaría tener que hacer
referencia a las bibliotecas de ADO y ADOX, mediante la interoperabilidad
COM de .NET, lo que no significa que en el sistema del usuario final de
tu
aplicación no haya que instalar los Componentes de Acceso a Datos de
Microsoft (MDAC), tal y como indicaré posteriormente.

El problema se presenta al momento de instalar dicha aplicación en un
cliente. Realizo la instalación con un proyecto del tipo Setup con
VS2005 para desktop, que funciona perfectamente salvo por el hecho
que me presenta un error al instanciar las librerías de ADODB. El error
es algo asi como como que no existen o no se pueden encontrar los
ensamblados de ADODB. Intenté luego instalar la versión 2.7 o 2.8
del MDAC_TYP pero fue un intento fallido, el problema persiste.

Con independencia o no que tu aplicación haga uso de las biblioteca ADODB
y
ADOX, digamos que es requisito imprescindible instalar la versión 2.6 o
superior de los Componentes de Acceso a Datos de Microsoft, porque tales
componentes son requeridos si en nuestro proyecto de Visual Basic .net
utilizamos el espacio de nombres System.Data.OleDb o
System.Data.SqlClient,
por tanto, si dices que has ejecutado el archivo redistribuible
MDAC_TYP.exe, entiendo que en el equipo cliente se han instalado
correctamente los Componentes de Acceso a Datos de Microsoft.

Ahora bien, como dichas bibliotecas se utilizan mediante la
interoperabilidad COM que nos dispensa el marco de trabajo de .net,
deberás
de procurar que en la carpeta donde se encuentra el ejecutable de tu
aplicación, se encuentren igualmente los archivos correspondientes a los
ensamblados de importación de las mencionadas bibliotecas, es decir, que
en
la carpeta deberán de existir los siguientes archivos:

Interop.ADODB.dll
Interop.ADOX.dll

Si no se encuentran dichos archivos, obtendrás una excepción en tiempo de
ejecución, con un mensaje más o menos parecido al siguiente:

[...] No se puede cargar el archivo o ensamblado
'Interop.ADOX.Version=2.8.0.0, ni una de sus dependencias. El
sistema
no puede hallar el archivo especificado.[...]

Por tanto, en el archivo de distribución de tu aplicación deberás de
incluir
los mencionados ensamblados de importación, los cuales los podrás
encontrar
en la carpeta Debug o Release de tu proyecto, porque me imagino que se
habrán creado automáticamente. :-)

Despierta mi curiosidad el por qué el setup no "empaqueta" tambien las
referencias de ADODB asi como cualquier otra referencia o componente sin
problema

Ahí ya no llego. Desconozco el motivo por el cual dichos archivos no se
incluyen automáticamente en el archivo de instalación, pero eso no quita
que
tú los añadas manualmente al proyecto de instalación.

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.

"xavendano" preguntó:

¿Que pasa si algunos de los Dlls no existe? A pesar que tiene la copia
local en TRUE de su referencia.

Me refiero particularmente al caso de: Interop.ADODB.dll

Si el ensamblado de importación no existe en la carpeta de la aplicación,
lógicamente se producirá la excepción que te comenté en mi anterior mensaje.

Quiero comentarte que el caso de la biblioteca de ADO clásica, digamos que
es un tanto especial en .NET, y el archivo de ensamblado de importación
(Interop.ADODB.dll) se copiará en la carpeta de resultados, obviamente si
has establecido a True el valor «Copia local» de las propiedades de la
referencia, y dicha referencia se corresponde con la biblioteca «Microsoft
ActiveX Data Objects 2.x Library», la cual se encuentra en la pestaña COM
del cuadro de diálogo «Agregar referencia».

Pero ocurre que los ingenieros de Microsoft, teniendo en mente que los
usuarios podrían seguir utilizando en sus proyectos la biblioteca de ADO
clásica, decidieron incluir la biblioteca de ADO en el GAC (Caché de
Conjunto Global), de ahí que si observas la pestaña .NET del cuadro de
diálogo «Agregar referencia», observarás que entre los primeros elementos de
la lista aparece la biblioteca ADODB. Si en tu proyecto referencias ésta
biblioteca, en lugar de referenciar la que aparece en la pestaña COM, no se
copiará el ensamblado de importación en la carpeta de resultados, porque por
defecto, el valor «Copia local» de la referencia es False, y no tendrás
problema alguno de utilizar la biblioteca de ADO clásica, porque ya existe
la copia en el GAC. Por supuesto que si estableces el valor en True, se
copiará el ensamblado en la carpeta de la aplicación, pero vuelvo a
insistir, que no es necesario por la existencia de una copia en el GAC.

En resúmen, si decides utilizar en tu proyecto la biblioteca de ADO,
establece la referencia a la citada biblioteca en la pestaña .NET, en lugar
de utilizar la que aparece en la pestaña COM del cuadro de diálogo «Agregar
referencia». Pero para utilizar la biblioteca de ADOX, necesariamente
tendrás que especificar la referencia COM, y procurar que el valor «Copia
local» sea True, para que se cree el ensamblado de importación, el cual
deberás de distribuir junto con el resto de archivos que conforman tu
aplicación.

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.