Problems with "msadodc.ocx"

Hi guys, thanks for reading my question. I think my biggest problem is that I'm not exactly sure how to even WORD a search for this particular problem, so I've never had any luck on Google or in your search parameters.

When I write a program in Visual Basic 6.0 that just so happens to call a Microsoft Access database file (with msadodc.ocx), it won't read it on another computer that doesn't have VB6 installed. The program loads, and the database is read, but it shows absolutely no information and you can't write to the database at all.

Specifically, on my computer when I look at either the project in progress, or the compiled version of the program, it loads, shows data perfectly, everything. But as soon as Joe Blow on another computer who's testing it out for me runs it, the problem loads, acts like there are no database problems, but then shows absolutely no information from the database. As if it's a clean .mdb file, (which it absolutely is not.)

Note, I've always had problems with the VB Package & Deployment Wizard, so I figured out long ago that if I just include all the needed files in the folder with the program, then there's no installation needed and people can run the compiled program just fine. However, even with all the needed files for anything to do with using msadodc.ocx, the program will run, but show nothing from the database.

What extra files do I need to include in the package to make it run on another computer? I thought at first it was the Microsoft Jet files, but when I attempted to run that it said that a previous service pack had already updated these files. I'm stumped.

Help? Or help me figure out the search parameters to look for it?

Thanks in advance!

MrGravity,

I'm not quite sure, but it might be a licensing problem with the OCX that I encountered just recently in one of my own projects, with another OCX and in Excel though. You may want to have a look at the thread titled Excel 2003 VBA: Exporting chart, FileDialog. I don't yet know how to link you to a particular post within the thread while still letting you see the entire thread. But have a look at post #11 by vb5prgrmr in that thread, in particular the MSKB article he links to from there.

HTH

Ah, and... Welcome at CodeGuru! :D

You didn't post the OS, but that might be the best reason to use an installer. There are some files that cannot be copied onto a different OS (or it could crash)

Office product files can't be copied and registered.

You can easily open an Access DB, and display it into a RichTextBox Control.

Take a look at the link in my signature. If gives an example.

The package and deployment wizard typically works fine.
Just placing the files on the computer is not always enough. Some files require you to register them.

I would not use the ADODC. Instead use ADODB code. No ocx needed and gives you more control.

I'm not sure that those really help me alot. Except, DataMiser, do you know where I can find the adodb code? It might help if I didn't actually have to use that ocx like you said.

Thanks for the tips tho, guys.

There are tons of examples all over the net.

You can also get a sample using the data form wizard within VB. By default it will use the ADODC but you can select ADO code or Class and it will generate those instead and will not use a control for data access.

Thanks folks, but I decided to go a different route entirely. I've written a converter to turn my .mdb into datafiles, which work out better in the end for what I'm doing.

Thanks anyway!

Okay... I'm back. Let's revive this thread because, well, I had a great idea. What I did was attempt to register those files immediately at runtime. Works GREAT! ... in XP.

Why in the name of god would it work perfectly in XP, but not in Vista or 7? I do realize they have problems running some older things, but just take a look at this code.

(I'm quite aware this code may be ugly. Right now, I'm just trying to get it to work!)

GLOBAL DECLARATIONS TIME THE PROGRAM STARTS

' OCX registering
Private Declare Function RegComCtl32 Lib "MSADODC.OCX" Alias "DllRegisterServer" () As Long
Private Declare Function RegComCtl33 Lib "COMDLG32.OCX" Alias "DllRegisterServer" () As Long
Private Declare Function RegComCtl34 Lib "mscomctl.ocx" Alias "DllRegisterServer" () As Long

' DLL registering
Private Declare Function RegisterTestDLL1 Lib "asycfilt.dll" Alias "DllRegisterServer" () As Long
Private Declare Function RegisterTestDLL2 Lib "COMCAT.DLL" Alias "DllRegisterServer" () As Long
Private Declare Function RegisterTestDLL3 Lib "MSBIND.DLL" Alias "DllRegisterServer" () As Long
Private Declare Function RegisterTestDLL4 Lib "MSSTDFMT.DLL" Alias "DllRegisterServer" () As Long
Private Declare Function RegisterTestDLL5 Lib "msvbvm60.dll" Alias "DllRegisterServer" () As Long
Private Declare Function RegisterTestDLL6 Lib "oleaut32.dll" Alias "DllRegisterServer" () As Long
Private Declare Function RegisterTestDLL7 Lib "olepro32.dll" Alias "DllRegisterServer" () As Long
Private Declare Function RegisterTestDLL8 Lib "VB6STKIT.DLL" Alias "DllRegisterServer" () As Long

Const ERROR_SUCCESS = &H0

Dim retCode As Long

---------------------------------


Private Sub registerTheseThings()

On Error resume next

' Register the .ocx file NOW.
' move to the DLL's directory
ChDrive "C:"
ChDir "C:\items"
' register the DLL
retCode = RegComCtl32()
retCode = RegComCtl33()
retCode = RegComCtl34()
'retCode = RegisterTestDLL1()
retCode = RegisterTestDLL2()
retCode = RegisterTestDLL3()
retCode = RegisterTestDLL4()
retCode = RegisterTestDLL5()
retCode = RegisterTestDLL6()
retCode = RegisterTestDLL7()
'retCode = RegisterTestDLL8()

End Sub


Anything thoughts? Do I need to reword these declarations and file-registering lines for different operating systems? As stated above, on my old XP laptop that doesn't have VB or Office installed, it opens, runs PERFECTLY. Give the exact same set of files to someone running Vista or 7, bam. Error code 339. I am absolutely CERTAIN the file exists, is named properly, isn't "not found", and is NOT read only.

I'm about to pull my hair out!! Thanks for looking.

Are you actually placing these dlls in a folder named C:\items and registering them there?

Say it isn't so. This is definitely not the way to do it and can introduce problems in existing software as well. DLLS especially system DLLS belong in the system area and you must check to make sure that there is not already a newer version of this dll registered on the system.

Windows Vista and Windows 7 are likely preventing you from doing this as windows XP and the software police should as well.

I had no idea. Maybe I should rethink this. Thanks for the heads up.