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?
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.
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.
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
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.