Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 537
  • Last Modified:

method '~' of object '~' failed


I am getting exactly the same symptoms as described on this page
however the advice is a little out of date

The program I have written is in VB6 and connects to an A2k3 database. It works fine on the development system but on transferring it onto a client system which has office 2k7 installed I find the error message upon any attempt to connect to the db.

I presume there is some kind of DAO dll/ocx involved which is different between 2k3 and 2k7, can anyone advise?

2 Solutions
Rey Obrero (Capricorn1)Commented:
see this link for different connection config to A2007 db.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
How does your VB6 program connect to the database? If you're using ADO, then cap's advice should work. If not, you'll need to let us know how the connection is being made.
I've seen this strange error myself.  I, too, still use some Access 2002/2003 databases.  In my case, I narrowed it down to corruption in the database.  Unfortunately, compact and repair did no good in those cases.  That only gave me a false sense of confidence that the db was fine - it wasn't.  Here's one suggestion: create a clean A2K3 database from scratch, and put one table in it, then try your test of connecting from VB6 to that new db.  Run your tests with those two files (the vb6 test app and the clean A2K2 db, both with non content of your legacy or suspect app or db) on different systems and see if you still get the problem or not.  (You probably won't.)  If you don't get the problem, then that would be an indication of some "corruption" in the A2K3 db, even though it works on the development system.  If you do get the problem, then the problem is outside the environment of the VB6 and db files.  You can stop reading this message because it won't apply.

===Do the following on the development machine===

If you find this new setup works on different systems as expected (this is important: with a clean fresh copy of a A2K3 db and none of the content from the suspect db), I end up doing one or two of the following two things.  The first set is easier, the second is more time consuming, but generally has been very reliable.

Create a new db with the old content:
1. Create a clean db.
2. Import all objects from the suspect db to the new db. (IMPORTANT: During this step, if it stops on any object, write that object's name down, then continue to import the rest of the objects.)
3. Open both copies of the db's in two different instances of Access in side-by-side windows.
4. Open the Startup Options and copy the settings from the suspect db to the new db.

If you had errors while importing any of the objects, this is in indication that those are the objects that are corrupted.  (Not good, because here comes the time consuming part.)

For each object that is indicated as corrupt during the first phase above (mine have always been forms or reports), those objects won't be created in the new db.  You will need to recreate them, but not necessarily from scratch.  For each:
1. Again, open both the suspect db and the new db in side-by-side Access instances.
2. In the new db, start a new version of that object (probably form or report) in the new db
3. Copy from the suspect db the UI elements of the object directly onto the new object's UI.
4. (Note: code is handled slightly differently - I learned this from a MS tech many years ago) Copy the code from the suspect db to Notepad, then select and copy the code from Notepad to the new object code module.  (If you have Access set to only show one module at a time as opposed to all modules, you can change you Options so that you can copy all code at once instead of one module at a time.)
5.  Save the new object, and repeat for any other objects that indicated corruption.

==Now compile and test your new db on the development system and other test systems.==  

This process also works wonders on reducing the size of your db after a lot of development has been done.  The db can get bloated with all the adds/edits/deletes of the access objects.  I've seen some circumstances where my db is reduced more than 50% in size just getting rid of all the junk left over from the many changes. It's obviously much easier to roll out when it is a smaller size as well.

Now, for me, in one case, after all that, there is one more circumstance that still experienced the problem you described.  If you thought the second phase was time consuming, this is worse, but it saved my bacon.  In my case, one of the forms that wouldn't import was still corrupted.  If I remember correctly, the way I figured out which one was corrupted was by treating the "new" db as suspect and imported into another clean db.  Or I just had one bad form and I used the original suspect db, either way, I narrowed down to one form that was the cause.  For this discussion, let's call it "new-new".  This "new-new" db didn't have the suspect form.  I created a new form to replace the bad one, and little by little copied over form elements, and tested along the way, until I found something that didn't work or caused a problem.  Ideally, you'd recreate this form from scratch, but often there are oodles (technical term) of elements and recreating from scratch is no fun.

Hope those ideas help you.
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Chris Raisin(Retired Analyst/Programmer)Commented:
Just one time this error occurs on a developemnt machine: This error will always happen when you open up VB6 and you ALREADY have it running. (It is probably showing in your Windows Task Manager under processes but is not visible on the desktop).

This is usuall ya result of a crash where VB6 has not closed properly.

When it happens, just check to see if it is obviously running (i.e. another instance on your desktop). If it is, simply close the current one showing the error, and open up the running instance as per normal (maximise). It will all work OK from there.

If the running instance is NOT visible on your desktop, close the current one, check in Task Manager under processes for "VB6.EXE" and if you find it, right click on it and select "End Process", then click "Yes" to accept the warning.

The problem always arises from either a nad shurdown of VB6 or and instance of VB6 already running.

I often see it when I have bugs crashing my code, and so I am aware of how it happens and the solution around it.

So on a client machine, I would assume they could paerhaps already have an instance runnig. Perhaps they clicked TWICE when starting the program, or the program runs something itslef on startup which starts another VB6 app which uses resources used by the current app. (Data/Files). Just some thoughts.....
I run multiple instances of vb6 simultaneously all the time without problems.
daz84Author Commented:
Thank you all very much for your responses. I ended up working around the problem by convincing the client to remove 2007 and install 2010.

I will try my best to get some office time to test the above solutions in order to properly close the question so it may be of more use to others


Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now