Provider cannot be found. It may not be properly installed.

[treyball3]

I'm writing an application in VB.Net 2005. As I get to a good stopping point, I compile and build an install and send it to our tester friend. This is my first program that will need to be installed on Vista. The first version I gave him worked just great. But the second version I'm getting the error "Provider cannot be found. It may not be properly installed." I know this has to do with not being able to find the database, but I can't figure out the problem.

Between the first version and the second version, I renamed a bunch of the tables in my access database. We had problems because I didn't know about compatibility files. I figured that out and uninstalled the old version and erased all files left behind in the user's directory on vista. The old version would install into ProgramData\SubFolder and then when you ran the software it would create copies in the user's ProgramData\SubFolder and would run from there. Well, this new version never copies the database to the user's ProgramData folder. So, then I get the error mentioned above when the program loads and tries to access the database. But also, if I manually copy the database where it needs to go, I still get the error.

I also had updated from Office 2003 to Office 2007 on my development machine between the two versions, but the database is still in Access 2003. I do make changes to the 2003 version using Access 2007 though. I'm not sure if that matters. The software still works fine on my XP development machine. And also on my Vista laptop. But for some reason it's not copying files like it's supposed to on the tester's computer.

Has anyone seen behavior like this before? I've been googling, but I can't seem to find anything specifice.

Thanks!

 

[treyball3]

I guess a couple other things I should mention... I have Vista Business on my laptop. And the tester has Vista Home Premium. On my laptop, the main program installs to C:\Program Files\ (with data still going to ProgramData), but on the tester's computer it goes to C:\Program Files (x86)\, even if I try to point it to regular C:\Program Files\ (he has both directories). On my computer I only have C:\Program Files. I'm not sure that has anything to do with it, because the first version worked fine, and the setup project hasn't changed, nor has the db location or connection string. I'm just trying to put as complete information out as I can


Thanks - Todd

 

[Sorwen]

It should be the version of office used. 2003 uses Jet and 2007 uses Ace no matter which version the file is saved as. So depending on how you have it setup (say if you are using the Server Explorer) then it would be trying to use the wrong Provider Ace when he needs it to use Jet. That is usually what the message means. If he has access 2007 and still gets the error I have no clue. The only thing I can suggest is to not use Solution Explorer and setup the bindings yourself. There maybe another way around it, but I don't use the Solution Explorer. I don't know if you can get the Ace provider as a separate download like you could get Jet in the past.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[treyball3]

He has office 2007 on his computer, but my software worked fine on his computer with the first version I sent him, so it had to have used Jet correctly I would think. I have a connection string in my code to connect to the db...

"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) & "\ProgramName\" & _
gsDatabaseName & ";Persist Security Info=False;Jet OLEDB:Database Password=" & gsDatabasePassword

This really has me stumped...


Thanks - Todd

 

[Sorwen]

You could try the Ace version. Should be something sort of like this:

"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) & "\ProgramName\" & _
gsDatabaseName & ";Persist Security Info=False;User ID =" <insert user id here> & ";Password=" & gsDatabasePassword

I use Persist Security Info = True, but I don't know that will matter. I'm not the best with connection strings.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[treyball3]

If I use Ace, will that work on machines that don't have Office 2007? Or is there an include I'll need for those older machines?


Thanks - Todd

 

[Sorwen]

No only 2007. But only older machines that have Office 2003- or Jet installed will run the other as well. But if you use the other and it works then you know something on his end changed. Something I didn't think about is you could also search for either Jet/Ace or check which version of Office is installed and then set the string by that.

This returns the version of Access installed. It is modified from some code I found else where and don't remember where.

    Private Function VersionInstalled1() As Integer
        Const stXL_SUBKEY As String = "\Access.Application\CurVer"

        Dim rkVersionKey As RegistryKey = Nothing
        Dim stVersion As String = String.Empty
        Dim stXLVersion As String = String.Empty

        Dim iVersion As Integer = Nothing

        Try
            rkVersionKey = Registry.ClassesRoot.OpenSubKey(Name:=stXL_SUBKEY, writable:=False)

            If rkVersionKey Is Nothing Then
                iVersion = 0

                Return iVersion
            End If

            stXLVersion = CStr(rkVersionKey.GetValue(Name:=stVersion))

            Dim ExcelVersionInfo As String() = stXLVersion.Split(".")

            Return ExcelVersionInfo(ExcelVersionInfo.Length - 1)
        Catch ex As Exception
            MsgBox(ex.ToString)
            Return Nothing
        Finally
            If Not rkVersionKey Is Nothing Then
                rkVersionKey.Close()
            End If
        End Try
    End Function

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[treyball3]

I'll give that a try, but one more question. What about computers that don't have Office at all? Right now I'm including the adodb.dll in the install, which works on my Vista test machine, because I don't have office installed.


Thanks - Todd

 

[Sorwen]

Jet came with a lot of old Microsoft things so often it can end up on computers without office yet it is still very possible it will not be on some ones computer and inversely as far as I've seen Ace doesn't come with much besides Office. Since you are running Vista it isn't likely it has either. No adodb.dll isn't enough. You are going to have to have Jet or Ace installed to speak with an Access Database.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[treyball3]

Thanks. Is there a way to install either of those with the install? Is it just another reference needed in my setup and deployment project?

Sorry if my questions are rookie... I've not done an install before.

thanks again!


Thanks - Todd

 

[Sorwen]

I'm sure the is a way to do so, but I've never done it so I couldn't tell you how. The one time I needed Jet and didn't have it I downloaded the redistributable, but I don't think they have the Jet one any more and I don't know about Ace. Your best bet is to check Microsoft though.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[Christineeve]

Try looking at this thread that helped me:

http://www.tek-tips.com/viewthread.cfm?qid=1509763&page=1

Search down to "Connection Strings."

http://www.connectionstrings.com

 

[Bluejay07]

it goes to C:\Program Files (x86)\, even if I try to point it to regular C:\Program Files\ (he has both directories).

If the machine has 'Program Files (x86)' and the program is installing to this directory, DO NOT TRY TO CHANGE THIS.

This machine is a 64bit machine and only 64bit programs should be installed in the C:\Program Files.

All 32bit programs should be installed in 'Program Files (x86)'.

I don't think you are in this case, however, if you are using ODBC connections, make sure you are using the correct version of ODBC32.exe. I believe the 64bit machine ODBC connections for 32bit programs are stored in WOW64 folder.