none
Problemas con Access y Visual Studio RRS feed

  • Pregunta

  • Por problemas con mi equipo reinstalé Windows 10 (64 bits), Office  2013 y Visual Studio 2015 (Que antes ya estaban instalados exactamente igual). Ahora cuando comienzo a trabajar de nuevo, mi base de datos (.accdb de Access) no conectaba, inicialmente porque y que los drivers de oledb 12 no estaban registrados, los descargue e instalé. El error ahora dice: "No se puede abrir su base de datos. Es posible que su aplicación no reconozca este tipo de base de datos o que el archivo esté dañado"

    Y he intentado todo lo que he encontrado en Internet y en las "desayudas" de Microsoft. Hay solo una cosa rara, con las bases de datos Access (.MDB) ahora me puedo conectar (lo que antes no podía) y con las .ACCDB ahora no es posible cuando antes funcionaba bien.

    Alguna ayuda o información sobre cual es el problema sería apreciada


    MGilt

    viernes, 26 de enero de 2018 17:45

Respuestas

  • "Maximiliano Gil" escribió:

    > Windows 10: 64 Bits
    >
    > Office 2013: 64 Bits
    >
    > Microsoft.ACE.OLEDB.12.: aparentemente instalé la versión 2007
    > (Voy a probar si allí está el problema)
    >

    Si desde tu equipo de trabajo quieres hacer uso del proveedor Microsoft.ACE.OLEDB.12.0, tanto en sus versiones de 32 como de 64 bits, tienes que instalar los siguientes productos y en el orden en el que los indico.

    1º) Primero desinstalar el Controlador de 2007 Office System, si es que lo tienes instalado, porque entonces no vas a poder instalar el siguiente componente.

    2º) Instalar el Componente redistribuible del motor de base de datos de Microsoft Access 2010, versión de 64 bits.

    3º) Instalar nuevamente el Controlador de 2007 Office System: Componentes de conectividad de datos, que solo está disponible para 32 bits. Este último es el que nos permitirá crear conexiones y orígenes de datos desde el IDE de Visual Studio.

    En mi caso particular, tengo instalado Office 2016 de 64 bits, Office 2010 de 64 bits, y el controlador de Office 2007, este último solamente para poder crear orígenes de datos desde el IDE de Visual Studio, y probar las compilaciones realizadas para ejecutarse en equipos de 32 bits (x86) que hacen uso del proveedor Microsoft.ACE.OLEDB.12.0.

    Échale un vistazo a la siguiente conversación donde aparece una captura de pantalla de los Componentes de Access que tenía instalados en mi equipo de desarrollo por el año 2014, que es lo que te he explicado que tienes que tener instalado en tu equipo:

    Acceso a Access de ofice 2013

    > Password: Si lo tiene desde origen
    >
    > El error ahora dice: "No se puede abrir su base de datos. Es posible que su aplicación
    > no reconozca este tipo de base de datos o que el archivo esté dañado"
    >
    > El error que se menciona lo da cuando intento abrir la BD

    Mi experiencia me indica que ese mensaje de error se produce porque la base de datos está protegida con una contraseña, la cual se estableció mediante la propia interfaz de usuario de Access 2010 o superior, y estás intentando abrir la conexión mediante el Controlador de Office 2007, el cual no soporta el método de cifrado predeterminado de Access 2010 o superior, por tanto, si has instalado el Componente redistribuible del motor de base de datos de Microsoft Access 2010 de 64 bits, no te va a quedar más remedio que compilar tu aplicación de Visual Basic para que se ejecute para plataformas de destino x64, si es que la quieres ejecutar en tu propio equipo de trabajo. Por supuesto, desde el IDE de Visual Studio tampoco vas a poder abrir esa base de datos cuando desees crear una conexión o un origen de datos.

    En cuanto a los usuarios de tu aplicación, estos la podrán abrir tanto si tienen instalada la versión de 32 o de 64 bits de los Componentes de Access 2010, por lo que deberás de tener dos compilaciones de tu programa: una para plataformas x86 (32 bits) y otra para plataformas de x64 (64 bits).

    Te advierto que el problema no se resuelve eliminando la contraseña de la base de datos, porque la versión del propio archivo no se modificará, obteniendo en este caso el siguiente mensaje de error a la hora de abrir la conexión: No se reconoce el formato de base de datos 'C:\Carpeta\Base.accdb'.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    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.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.


    sábado, 27 de enero de 2018 3:12
    Moderador
  • "MGilT" preguntó:

    > Ahora bien creo que hay que seguir investigando. Ya que en mi máquina original,
    > todo me funcionaba muy bien. Te explico: Tenía mi BD con password y se conectaba
    > y podia compilar para 32 bits. Ahora (por lo que me informaste) cree una BD
    > (Access 2013) con una tabla, me conecto, importé las tablas de la otra base de
    > datos, me conecto, le coloco password, ya no hay conexión y si le quito el
    > password (tal como me dijiste) tamoco se conecta...

    Investigar puedes seguir investigando todo el tiempo que creas conveniente, pero por lo que yo investigué hace tiempo ya, te comento que el problema está en que estás utilizando el proveedor Microsoft.ACE.OLEDB.12.0 para conectarte desde una aplicación .NET con la base de datos de Access protegida desde la propia interfaz de usuario de Microsoft Access 2013, con lo que el formato de archivo cambia para que solamente pueda ser abierta por los Componentes de Access 2010 o superior, por tanto, si la aplicación que desea abrir esa base de datos *.accdb protegida la has compilado para ser ejecutada en plataformas de 32 bits, los equipos cliente deberán tener instalado, sí o sí, los Componentes del motor de base de datos de Access 2010 de 32 bits, salvo que la base de datos se abra directamente desde la propia interfaz de usuario de Microsoft Access 2010, 2013 o 2016, pero claro, lo que pretendemos es trabajar con la base de datos de Access desde nuestra propia aplicación .NET (con independencia del lenguaje de programación que se haya utilizado para compilarla), y no desde la interfaz de usuario de Microsoft Access.

    El formato de archivo de la base de datos protegida mediante la propia interfaz de usuario de Access 2010, 2013 o 2016 tendrá el valor de la constante dbVersion140 (una constante existente en la biblioteca DAO de Microsoft Access), el cual viene a decirnos que la base de datos utilizará el formato de archivo del motor de base de datos de Microsoft Access versión 14.0 (Access 2010). Si tú intentas abrir esa base de datos con el formato de archivo de Access 2010 desde una aplicación .NET utilizando los componentes de 32 bits de Access 2007, obtendrás el error que estás obteniendo: No se puede abrir su base de datos. Es posible que su aplicación no reconozca este tipo de base de datos o que el archivo esté dañado. Y si anulas la contraseña, entonces recibirás éste otro mensaje de error: No se reconoce el formato de base de datos 'C:\Carpeta\Base.accdb'.

    Si quieres trabajar con un archivo *.accdb protegido con contraseña, y que éste se pueda abrir tanto desde tu propia aplicación .NET como desde la interfaz de usuario de Access 2007 o superior, con independencia de la versión de 32 o 64 bits con la que hayas compilado la aplicación, tienes que crearla y protegerla desde el propio Microsoft Access 2007, para que el formato de archivo tenga el valor de la constante dbVersion120 (formato de archivo del motor de base de datos de Microsoft Access versión 12.0 [Access 2007]). Ahora bien, si no proteges con una contraseña la base de datos *.accdb, entonces la podrás abrir con cualquier versión de Microsoft Access 2007 o superior. ;-)

    Como información complementaria, lo mismo te resulta útil la lectura del siguiente artículo:

    Programación de datos con Microsoft Access 2010

    > ... Será que Microsoft quiere que usemos otras bases de datos de su competencia,
    > porque yo ( y muchos programadores) nos negamos a usar Microsoft SQL, y no porque
    > sea malo, sino porque le creamos un costo adicional a nuestros clientes, que son
    > dificiles de convencer.
    >

    Por si lo ignoras te comento que hay versiones gratuitas de SQL Server, y quizás puede que la que más se adapte para sustituir la base de datos de Access sea la versión SQL Server Express LocalDB. Si tienes alguna pregunta o duda sobre estas versiones, te aconsejaría que la realizaras en el foro en español de Microsoft SQL Server.

    > Gracias de nuevo y te marco la repuesta

    ¡Bueno! Más que Marcar como respuesta, lo que has hecho es "marcar" Proponer como respuesta. ;-)


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    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.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.


    sábado, 27 de enero de 2018 8:57
    Moderador
  • "Maximiliano Gil" escribió:

    > si conozco SQL Express aunque no se cuan bueno es (Ya que es gratuito y
    > Microsoft no da nada gratuito con las funciones necesarias para un desarrollador).

    Si a tu aplicación de Visual Basic .net le es suficiente con un simple archivo de Access, entiendo que igual de suficiente, o más, le sería trabajar con una base de datos de SQL Server Express (si la base de datos la vas a alojar en un servidor SQL Server), o de LocalDB (si vas a trabajar con una base de datos de escritorio al igual que lo haces con Access). Otra cuestión diferente sería si en lugar de abrir la base de datos con una aplicación .NET la abrieras directamente desde la propia interfaz de usuario de Microsoft Access 2007 o superior, donde crearías tus formularios, informes y demás objetos que proporciona la biblioteca de objetos de Microsoft Access. En definitiva, trabajar con una "aplicación" de Access en lugar de trabajar con una aplicación de Visual Basic, C#, o de cualquier otro lenguaje .NET, ya que en este caso necesariamente tendrías que utilizar el proveedor de datos Microsoft.ACE.OLEDB.12.0 si es que quieres abrir la base de datos, claro está.

    ¡Hombre! También te podrías olvidar del citado proveedor de datos y referenciar en tu proyecto la biblioteca de objetos correspondiente a la versión de Microsoft Access que desees utilizar. Pero salvo que conozcas bien los objetos disponibles en dicha biblioteca de objetos y tengas bastante soltura para desenvolverte con ellos sin ningún tipo de problema, yo desde luego que no te la aconsejaría, aparte de que tu aplicación estaría sujeta a la versión de Microsoft Access que hayas referenciado en tu proyecto, salvo que decidas no referenciar en tiempo de diseño ninguna biblioteca de Access y referenciarla en tiempo de ejecución utilizando técnicas de reflexión, lo que implica tener que conocer las clases del espacio de nombres System.Reflection y saberte de memoria todas las implementaciones de las clases de objetos de Microsoft Access que deseas utilizar. Te aseguro que es un gran trabajo que ignoro si te merecerá la pena realizar tamaño esfuerzo. ;-)

    > Una pregunta y disculpa, si yo hago una Base de datos, digamos en Access 2016,
    > protegida con contraseña voy a tener los mismos problemas? Esto te lo pregunto
    > ya que encontré ciertas inconsistencias en Access 2007 y no quisiese usarlo.
    > Lo otro es que no entiendo por qué teniendo licencia de Office (Access) y de
    > VS 2015 ambos son incompatibles. Desde mi punto de vista Microsoft pareciera
    > hacerlo adrede: Molestar a los desarrolladores

    ¡Bueno! Yo entiendo a Microsoft como lo que realmente es: una empresa de software que necesita actualizar sus productos de acuerdo a lo que requieren las circunstancias del momento y a lo que demanden los usuarios de sus productos. Ten en cuenta que hay muchos usuarios, incluidos empresas, que trabajan con bases de datos de Access desde el propio Microsoft Access, no desde una aplicación desarrollada con un lenguaje de programación concreto.

    El "problema", si es que se pueda llamar así, es que hay dos opciones para trabajar con bases de datos de Access: mediante el correspondiente proveedor de datos OleDb u ODBC, o directamente mediante Microsoft Access. Y por lo que llevo observando desde la aparición de Access 2013, parece ser que Microsoft se está inclinando porque se trabaje directamente desde el propio Microsoft Access, de hecho, y salvo que yo esté equivocado, ya no existen componentes redistribuibles correspondientes a Access 2013, 2016, y me imagino que tampoco los habrá para aquellas otras versiones de Microsoft Access que aparezcan en el futuro, tal y como sí existen versiones redistribuibles desde Access 2000 hasta Access 2010, cuyos componentes son los que nos permiten conectarnos a las bases de datos de Access desde una aplicación con .NET o sin .NET.

    Todo esto nos puede gustar o no, pero es lo que hay. Aparte que entiendo que afortunadamente existe un sustituto para trabajar con bases de datos de escritorio que no sean archivos de Access, como puede ser la mencionada LocalDB, que precisamente está destinada para los desarrolladores de programas de bases de datos y cuya instalación copia los archivos mínimos para iniciar el motor de base de datos Microsoft SQL Server. ¿Que el día de mañana a tu aplicación se le ha quedado pequeña LocalDB? Entonces sería cuestión de migrar a una base de datos de servidor SQL Server, que bien puede ser su versión Express.

    En definitiva, que soluciones hay, por lo que yo al menos no puedo decir que Microsoft quiera "fastidiar o molestar" a los desarrolladores con sus decisiones empresariales.

    NOTA: Por la fotografía del perfil, entiendo que los usuarios Maximiliano Gil y MGilT son la misma persona. Pero como la pregunta la ha iniciado el usuario Maximiliano Gil, te comento que será este el único usuario que podrá marcar las respuestas como satisfactorias. ¿De acuerdo? ;-)


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    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.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.



    sábado, 27 de enero de 2018 11:35
    Moderador
  • "Maximiliano Gil" escribió:

    > Gracias por toda esa información y opinión Enrique. Se te agradece

    De nada, pero ya que estás utilizando una base de datos de Access protegida con una contraseña, se me ha olvidado comentarte otro aspecto que considero importante en cuanto a la seguridad de la propia base de datos, el cual consiste en que la contraseña de la base de datos se podrá leer perfectamente con solo obtener el valor de la propiedad ConnectionString del objeto OleDbConnection que hayas utilizado para establecer la conexión con la base de datos, aunque hayas especificado el parámetro Persist Security Info=false, que dicho sea de paso es el valor predeterminado aunque no se establezca explícitamente dicho parámetro en la cadena de conexión.

    Si deseas verlo con tus propios ojos, tan solo tienes que ejecutar lo siguiente:

    Imports System.Data.OleDb
    
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    
            Try
                Using cnn As New OleDbConnection()
                    ' Establecer la cadena de conexión.
                    cnn.ConnectionString =
                        "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Mis documentos\Database1.accdb;" &
                        "Jet OLEDB:Database Password=contraseña;Persist Security Info=false"
    
                    ' Abrir la conexión.
                    cnn.Open()
    
                    ' Leer la cadena de conexión una vez abierta la conexión.
                    MessageBox.Show(cnn.ConnectionString)
                End Using
    
            Catch ex As Exception
                MessageBox.Show(ex.Message)
    
            End Try
    
        End Sub

    Y aquí tienes el resultado:


    El problema está en que el proveedor OleDb .NET, que es el que se utiliza para establecer la conexión con una base de datos de Access desde una aplicación .NET, hace caso omiso del parámetro Jet OLEDB:Database Password, aunque el parámetro Persist Security Info=false se encuentre establecido en la propia cadena de conexión. Por tanto, de nada sirve proteger la contraseña de la base de datos encriptada en el archivo de configuración de la aplicación, o en cualquier otro sitio, porque una vez abierta la conexión basta con leer el valor de la propiedad ConnectionString, la cual devolverá el valor de la misma como texto plano, tal y como muestra la captura de pantalla adjuntada.

    Si estás desarrollando una aplicación *.exe, pues lo mismo no tiene demasiada importancia, porque no creo que al usuario de tu aplicación le interese conocer la cadena de conexión completa. Pero si estás desarrollando una biblioteca *.dll, ten cuidado con lo que haces porque cualquier usuario de la biblioteca podrá aprovechar esa circunstancia para obtener la contraseña de la base de datos de Access. En estos casos es cuando suele aconsejar NO DECLARAR variables globales a nivel de la propia aplicación del tipo OleDbConnection, NI TAMPOCO IMPLEMENTAR procedimientos Function o Property que devuelvan un objeto OleDbConnection que contenga la cadena de conexión que se está utilizando en la aplicación, aunque se declaren en la clase o módulo como Private o Friend, porque mediante reflexión se podrá acceder a los mismos. Y lo mismo digo respecto de los objetos OleDbCommand, porque su propiedad Connection nos devolverá el objeto OleDbConnection al que pertenece el comando, por lo que podremos acceder perfectamente a la cadena de conexión.

    Así que, avisado quedas. ;-)

     


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    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.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.


    sábado, 27 de enero de 2018 17:42
    Moderador

Todas las respuestas

  • "Maximiliano Gil" escribió:

    > Por problemas con mi equipo reinstalé Windows 10 (64 bits), Office  2013 ...

    Hola, Maximiliano:

    Office 2013, ¿de 64 o de 32 bits? ¿Cuál de ellos has instalado?

    > Ahora cuando comienzo a trabajar de nuevo, mi base de datos (.accdb de Access)
    > no conectaba, inicialmente porque y que los drivers de oledb 12 no estaban
    > registrados, los descargue e instalé...

    Concretamente, ¿qué versión del proveedor Microsoft.ACE.OLEDB.12.0 es el que has instalado? Te lo pregunto porque si has instalado los componentes de Access 2007, este solamente está disponible para 32 bits. En cambio, si has instalado los componentes de Access 2010, existen versiones para 32 y 64 bits. ¿Cual de ellos has instalado?

    > ... El error ahora dice: "No se puede abrir su base de datos. Es posible que su
    > aplicación no reconozca este tipo de base de datos o que el archivo esté dañado"

    Ese error, ¿cuando se produce? ¿Quizás cuando quieres configurar una conexión, o un origen de datos, desde el IDE de Visual Studio 2015?

    Te hago saber que todas las versiones de Visual Studio son de 32 bits, por tanto, necesitarás la versión de 32 bits del proveedor Microsoft.ACE.OLEDB.12.0 si tu intención es crear una conexión de datos desde la ventana Explorador de servidores de Visual Studio 2015.

    ¿Por casualidad tu base de datos Access con extensión *.accdb está protegida con una contraseña? Si la respuesta es afirmativa, ¿cuando protegiste la base de datos? ¿Antes o después de instalar Office 2013?

    > Hay solo una cosa rara, con las bases de datos Access (.MDB) ahora me puedo
    > conectar (lo que antes no podía) ...

    Si puedes conectarte con una base de datos de Access extensión *.mdb, es porque quizás estés utilizando el proveedor Microsoft.Jet.OLEDB.4.0, el cual solamente existe para 32 bits, por tanto, en este caso sí puedes establecer una conexión, o un origen de datos, desde el IDE de Visual Studio 2015.

    > ...  y con las .ACCDB ahora no es posible cuando antes funcionaba bien.

    Porque puede que antes tuvieras instalada la versión de 32 bits del proveedor Microsoft.ACE.OLEDB.12.0.

    Respóndeme a cada una de las preguntas que he realizado y posteriormente veremos lo que se puede hacer para solucionar el problema. Pero sin más detalles por tu parte, sería "estar pegando palos de ciego" con las posibles soluciones que tanto yo como cualquier otra persona te pudieran indicar. ;-)

    Un saludo


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    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.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.




    viernes, 26 de enero de 2018 18:11
    Moderador
  • Gracias por tu repuesta Enrique, se te agradece y voy primero a verificar lo de Microsoft.ACE.OLEDB.12.

    Windows 10: 64 Bits

    Office 2013: 64 Bits

    Microsoft.ACE.OLEDB.12.: aparentemente instalé la versión 2007 (Voy a probar si allí está el problema)

    Password: Si lo tiene desde origen

    El error que se menciona lo da cuando intento abrir la BD


    MGilt

    viernes, 26 de enero de 2018 22:48
  • "Maximiliano Gil" escribió:

    > Windows 10: 64 Bits
    >
    > Office 2013: 64 Bits
    >
    > Microsoft.ACE.OLEDB.12.: aparentemente instalé la versión 2007
    > (Voy a probar si allí está el problema)
    >

    Si desde tu equipo de trabajo quieres hacer uso del proveedor Microsoft.ACE.OLEDB.12.0, tanto en sus versiones de 32 como de 64 bits, tienes que instalar los siguientes productos y en el orden en el que los indico.

    1º) Primero desinstalar el Controlador de 2007 Office System, si es que lo tienes instalado, porque entonces no vas a poder instalar el siguiente componente.

    2º) Instalar el Componente redistribuible del motor de base de datos de Microsoft Access 2010, versión de 64 bits.

    3º) Instalar nuevamente el Controlador de 2007 Office System: Componentes de conectividad de datos, que solo está disponible para 32 bits. Este último es el que nos permitirá crear conexiones y orígenes de datos desde el IDE de Visual Studio.

    En mi caso particular, tengo instalado Office 2016 de 64 bits, Office 2010 de 64 bits, y el controlador de Office 2007, este último solamente para poder crear orígenes de datos desde el IDE de Visual Studio, y probar las compilaciones realizadas para ejecutarse en equipos de 32 bits (x86) que hacen uso del proveedor Microsoft.ACE.OLEDB.12.0.

    Échale un vistazo a la siguiente conversación donde aparece una captura de pantalla de los Componentes de Access que tenía instalados en mi equipo de desarrollo por el año 2014, que es lo que te he explicado que tienes que tener instalado en tu equipo:

    Acceso a Access de ofice 2013

    > Password: Si lo tiene desde origen
    >
    > El error ahora dice: "No se puede abrir su base de datos. Es posible que su aplicación
    > no reconozca este tipo de base de datos o que el archivo esté dañado"
    >
    > El error que se menciona lo da cuando intento abrir la BD

    Mi experiencia me indica que ese mensaje de error se produce porque la base de datos está protegida con una contraseña, la cual se estableció mediante la propia interfaz de usuario de Access 2010 o superior, y estás intentando abrir la conexión mediante el Controlador de Office 2007, el cual no soporta el método de cifrado predeterminado de Access 2010 o superior, por tanto, si has instalado el Componente redistribuible del motor de base de datos de Microsoft Access 2010 de 64 bits, no te va a quedar más remedio que compilar tu aplicación de Visual Basic para que se ejecute para plataformas de destino x64, si es que la quieres ejecutar en tu propio equipo de trabajo. Por supuesto, desde el IDE de Visual Studio tampoco vas a poder abrir esa base de datos cuando desees crear una conexión o un origen de datos.

    En cuanto a los usuarios de tu aplicación, estos la podrán abrir tanto si tienen instalada la versión de 32 o de 64 bits de los Componentes de Access 2010, por lo que deberás de tener dos compilaciones de tu programa: una para plataformas x86 (32 bits) y otra para plataformas de x64 (64 bits).

    Te advierto que el problema no se resuelve eliminando la contraseña de la base de datos, porque la versión del propio archivo no se modificará, obteniendo en este caso el siguiente mensaje de error a la hora de abrir la conexión: No se reconoce el formato de base de datos 'C:\Carpeta\Base.accdb'.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    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.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.


    sábado, 27 de enero de 2018 3:12
    Moderador
  • Gracias Enrique. Te comento, lo que dices tiene sentido y hecho las confirmaciones. Estás en lo cierto. Pero me pregunto: ¿Cual es la causa dde que Microsoft nos complique la vida a los desarrolladores, sin nosotros ellos no serían lo que son?

    Ahora bien creo que hay que seguir investigando. Ya que en mi máquina original, todo me funcionaba muy bien. Te explico: Tenía mi BD con password y se conectaba y podia compilar para 32 bits. Ahora (por lo que me informaste) cree una BD (Access 2013) con una tabla, me conecto, importé las tablas de la otra base de datos, me conecto, le coloco password, ya no hay conexión y si le quito el password (tal como me dijiste) tamoco se conecta. Será que Microsoft quiere que usemos otras bases de datos de su competencia, porque yo ( y muchos programadores) nos negamos a usar Microsoft SQL, y no porque sea malo, sino porque le creamos un costo adicional a nuestros clientes, que son dificiles de convencer.

    Gracias de nuevo y te marco la repuesta

    sábado, 27 de enero de 2018 6:28
  • "MGilT" preguntó:

    > Ahora bien creo que hay que seguir investigando. Ya que en mi máquina original,
    > todo me funcionaba muy bien. Te explico: Tenía mi BD con password y se conectaba
    > y podia compilar para 32 bits. Ahora (por lo que me informaste) cree una BD
    > (Access 2013) con una tabla, me conecto, importé las tablas de la otra base de
    > datos, me conecto, le coloco password, ya no hay conexión y si le quito el
    > password (tal como me dijiste) tamoco se conecta...

    Investigar puedes seguir investigando todo el tiempo que creas conveniente, pero por lo que yo investigué hace tiempo ya, te comento que el problema está en que estás utilizando el proveedor Microsoft.ACE.OLEDB.12.0 para conectarte desde una aplicación .NET con la base de datos de Access protegida desde la propia interfaz de usuario de Microsoft Access 2013, con lo que el formato de archivo cambia para que solamente pueda ser abierta por los Componentes de Access 2010 o superior, por tanto, si la aplicación que desea abrir esa base de datos *.accdb protegida la has compilado para ser ejecutada en plataformas de 32 bits, los equipos cliente deberán tener instalado, sí o sí, los Componentes del motor de base de datos de Access 2010 de 32 bits, salvo que la base de datos se abra directamente desde la propia interfaz de usuario de Microsoft Access 2010, 2013 o 2016, pero claro, lo que pretendemos es trabajar con la base de datos de Access desde nuestra propia aplicación .NET (con independencia del lenguaje de programación que se haya utilizado para compilarla), y no desde la interfaz de usuario de Microsoft Access.

    El formato de archivo de la base de datos protegida mediante la propia interfaz de usuario de Access 2010, 2013 o 2016 tendrá el valor de la constante dbVersion140 (una constante existente en la biblioteca DAO de Microsoft Access), el cual viene a decirnos que la base de datos utilizará el formato de archivo del motor de base de datos de Microsoft Access versión 14.0 (Access 2010). Si tú intentas abrir esa base de datos con el formato de archivo de Access 2010 desde una aplicación .NET utilizando los componentes de 32 bits de Access 2007, obtendrás el error que estás obteniendo: No se puede abrir su base de datos. Es posible que su aplicación no reconozca este tipo de base de datos o que el archivo esté dañado. Y si anulas la contraseña, entonces recibirás éste otro mensaje de error: No se reconoce el formato de base de datos 'C:\Carpeta\Base.accdb'.

    Si quieres trabajar con un archivo *.accdb protegido con contraseña, y que éste se pueda abrir tanto desde tu propia aplicación .NET como desde la interfaz de usuario de Access 2007 o superior, con independencia de la versión de 32 o 64 bits con la que hayas compilado la aplicación, tienes que crearla y protegerla desde el propio Microsoft Access 2007, para que el formato de archivo tenga el valor de la constante dbVersion120 (formato de archivo del motor de base de datos de Microsoft Access versión 12.0 [Access 2007]). Ahora bien, si no proteges con una contraseña la base de datos *.accdb, entonces la podrás abrir con cualquier versión de Microsoft Access 2007 o superior. ;-)

    Como información complementaria, lo mismo te resulta útil la lectura del siguiente artículo:

    Programación de datos con Microsoft Access 2010

    > ... Será que Microsoft quiere que usemos otras bases de datos de su competencia,
    > porque yo ( y muchos programadores) nos negamos a usar Microsoft SQL, y no porque
    > sea malo, sino porque le creamos un costo adicional a nuestros clientes, que son
    > dificiles de convencer.
    >

    Por si lo ignoras te comento que hay versiones gratuitas de SQL Server, y quizás puede que la que más se adapte para sustituir la base de datos de Access sea la versión SQL Server Express LocalDB. Si tienes alguna pregunta o duda sobre estas versiones, te aconsejaría que la realizaras en el foro en español de Microsoft SQL Server.

    > Gracias de nuevo y te marco la repuesta

    ¡Bueno! Más que Marcar como respuesta, lo que has hecho es "marcar" Proponer como respuesta. ;-)


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    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.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.


    sábado, 27 de enero de 2018 8:57
    Moderador
  • Gracias Enrique, si conozco SQL Express aunque no se cuan bueno es (Ya que es gratuito y Microsoft no da nada gratuito con las funciones necesarias para un desarrollador).

    Una pregunta y disculpa, si yo hago una Base de datos, digamos en Access 2016, protegida con contraseña voy a tener los mismos problemas? Esto te lo pregunto ya que encontré ciertas inconsistencias en Access 2007 y no quisiese usarlo. Lo otro es que no entiendo por qué teniendo licencia de Office (Access) y de VS 2015 ambos son incompatibles. Desde mi punto de vista Microsoft pareciera hacerlo adrede: Molestar a los desarrolladores


    MGilt

    sábado, 27 de enero de 2018 10:23
  • "Maximiliano Gil" escribió:

    > si conozco SQL Express aunque no se cuan bueno es (Ya que es gratuito y
    > Microsoft no da nada gratuito con las funciones necesarias para un desarrollador).

    Si a tu aplicación de Visual Basic .net le es suficiente con un simple archivo de Access, entiendo que igual de suficiente, o más, le sería trabajar con una base de datos de SQL Server Express (si la base de datos la vas a alojar en un servidor SQL Server), o de LocalDB (si vas a trabajar con una base de datos de escritorio al igual que lo haces con Access). Otra cuestión diferente sería si en lugar de abrir la base de datos con una aplicación .NET la abrieras directamente desde la propia interfaz de usuario de Microsoft Access 2007 o superior, donde crearías tus formularios, informes y demás objetos que proporciona la biblioteca de objetos de Microsoft Access. En definitiva, trabajar con una "aplicación" de Access en lugar de trabajar con una aplicación de Visual Basic, C#, o de cualquier otro lenguaje .NET, ya que en este caso necesariamente tendrías que utilizar el proveedor de datos Microsoft.ACE.OLEDB.12.0 si es que quieres abrir la base de datos, claro está.

    ¡Hombre! También te podrías olvidar del citado proveedor de datos y referenciar en tu proyecto la biblioteca de objetos correspondiente a la versión de Microsoft Access que desees utilizar. Pero salvo que conozcas bien los objetos disponibles en dicha biblioteca de objetos y tengas bastante soltura para desenvolverte con ellos sin ningún tipo de problema, yo desde luego que no te la aconsejaría, aparte de que tu aplicación estaría sujeta a la versión de Microsoft Access que hayas referenciado en tu proyecto, salvo que decidas no referenciar en tiempo de diseño ninguna biblioteca de Access y referenciarla en tiempo de ejecución utilizando técnicas de reflexión, lo que implica tener que conocer las clases del espacio de nombres System.Reflection y saberte de memoria todas las implementaciones de las clases de objetos de Microsoft Access que deseas utilizar. Te aseguro que es un gran trabajo que ignoro si te merecerá la pena realizar tamaño esfuerzo. ;-)

    > Una pregunta y disculpa, si yo hago una Base de datos, digamos en Access 2016,
    > protegida con contraseña voy a tener los mismos problemas? Esto te lo pregunto
    > ya que encontré ciertas inconsistencias en Access 2007 y no quisiese usarlo.
    > Lo otro es que no entiendo por qué teniendo licencia de Office (Access) y de
    > VS 2015 ambos son incompatibles. Desde mi punto de vista Microsoft pareciera
    > hacerlo adrede: Molestar a los desarrolladores

    ¡Bueno! Yo entiendo a Microsoft como lo que realmente es: una empresa de software que necesita actualizar sus productos de acuerdo a lo que requieren las circunstancias del momento y a lo que demanden los usuarios de sus productos. Ten en cuenta que hay muchos usuarios, incluidos empresas, que trabajan con bases de datos de Access desde el propio Microsoft Access, no desde una aplicación desarrollada con un lenguaje de programación concreto.

    El "problema", si es que se pueda llamar así, es que hay dos opciones para trabajar con bases de datos de Access: mediante el correspondiente proveedor de datos OleDb u ODBC, o directamente mediante Microsoft Access. Y por lo que llevo observando desde la aparición de Access 2013, parece ser que Microsoft se está inclinando porque se trabaje directamente desde el propio Microsoft Access, de hecho, y salvo que yo esté equivocado, ya no existen componentes redistribuibles correspondientes a Access 2013, 2016, y me imagino que tampoco los habrá para aquellas otras versiones de Microsoft Access que aparezcan en el futuro, tal y como sí existen versiones redistribuibles desde Access 2000 hasta Access 2010, cuyos componentes son los que nos permiten conectarnos a las bases de datos de Access desde una aplicación con .NET o sin .NET.

    Todo esto nos puede gustar o no, pero es lo que hay. Aparte que entiendo que afortunadamente existe un sustituto para trabajar con bases de datos de escritorio que no sean archivos de Access, como puede ser la mencionada LocalDB, que precisamente está destinada para los desarrolladores de programas de bases de datos y cuya instalación copia los archivos mínimos para iniciar el motor de base de datos Microsoft SQL Server. ¿Que el día de mañana a tu aplicación se le ha quedado pequeña LocalDB? Entonces sería cuestión de migrar a una base de datos de servidor SQL Server, que bien puede ser su versión Express.

    En definitiva, que soluciones hay, por lo que yo al menos no puedo decir que Microsoft quiera "fastidiar o molestar" a los desarrolladores con sus decisiones empresariales.

    NOTA: Por la fotografía del perfil, entiendo que los usuarios Maximiliano Gil y MGilT son la misma persona. Pero como la pregunta la ha iniciado el usuario Maximiliano Gil, te comento que será este el único usuario que podrá marcar las respuestas como satisfactorias. ¿De acuerdo? ;-)


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    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.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.



    sábado, 27 de enero de 2018 11:35
    Moderador
  • Gracias por toda esa información y opinión Enrique. Se te agradece

    MGilt

    sábado, 27 de enero de 2018 12:00
  • "Maximiliano Gil" escribió:

    > Gracias por toda esa información y opinión Enrique. Se te agradece

    De nada, pero ya que estás utilizando una base de datos de Access protegida con una contraseña, se me ha olvidado comentarte otro aspecto que considero importante en cuanto a la seguridad de la propia base de datos, el cual consiste en que la contraseña de la base de datos se podrá leer perfectamente con solo obtener el valor de la propiedad ConnectionString del objeto OleDbConnection que hayas utilizado para establecer la conexión con la base de datos, aunque hayas especificado el parámetro Persist Security Info=false, que dicho sea de paso es el valor predeterminado aunque no se establezca explícitamente dicho parámetro en la cadena de conexión.

    Si deseas verlo con tus propios ojos, tan solo tienes que ejecutar lo siguiente:

    Imports System.Data.OleDb
    
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    
            Try
                Using cnn As New OleDbConnection()
                    ' Establecer la cadena de conexión.
                    cnn.ConnectionString =
                        "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Mis documentos\Database1.accdb;" &
                        "Jet OLEDB:Database Password=contraseña;Persist Security Info=false"
    
                    ' Abrir la conexión.
                    cnn.Open()
    
                    ' Leer la cadena de conexión una vez abierta la conexión.
                    MessageBox.Show(cnn.ConnectionString)
                End Using
    
            Catch ex As Exception
                MessageBox.Show(ex.Message)
    
            End Try
    
        End Sub

    Y aquí tienes el resultado:


    El problema está en que el proveedor OleDb .NET, que es el que se utiliza para establecer la conexión con una base de datos de Access desde una aplicación .NET, hace caso omiso del parámetro Jet OLEDB:Database Password, aunque el parámetro Persist Security Info=false se encuentre establecido en la propia cadena de conexión. Por tanto, de nada sirve proteger la contraseña de la base de datos encriptada en el archivo de configuración de la aplicación, o en cualquier otro sitio, porque una vez abierta la conexión basta con leer el valor de la propiedad ConnectionString, la cual devolverá el valor de la misma como texto plano, tal y como muestra la captura de pantalla adjuntada.

    Si estás desarrollando una aplicación *.exe, pues lo mismo no tiene demasiada importancia, porque no creo que al usuario de tu aplicación le interese conocer la cadena de conexión completa. Pero si estás desarrollando una biblioteca *.dll, ten cuidado con lo que haces porque cualquier usuario de la biblioteca podrá aprovechar esa circunstancia para obtener la contraseña de la base de datos de Access. En estos casos es cuando suele aconsejar NO DECLARAR variables globales a nivel de la propia aplicación del tipo OleDbConnection, NI TAMPOCO IMPLEMENTAR procedimientos Function o Property que devuelvan un objeto OleDbConnection que contenga la cadena de conexión que se está utilizando en la aplicación, aunque se declaren en la clase o módulo como Private o Friend, porque mediante reflexión se podrá acceder a los mismos. Y lo mismo digo respecto de los objetos OleDbCommand, porque su propiedad Connection nos devolverá el objeto OleDbConnection al que pertenece el comando, por lo que podremos acceder perfectamente a la cadena de conexión.

    Así que, avisado quedas. ;-)

     


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    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.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.


    sábado, 27 de enero de 2018 17:42
    Moderador
  • Gracias de nuevo Enrique, esa información es importante y la desconocía. De todas maneras estoy evaluando SQL Expess 2017, donde aparentemente Microsoft deja un poco de control a los desarrolladores

    MGilt

    sábado, 27 de enero de 2018 19:39