Error 430

[FuzMic]

Hi members

I have a .mde created in Access.02.sp3 which works perfectly in a number of PC running winxp.sp2-3 and Access.runTime.07 (latest).

Recently i place the same in a PC with the same configuration as above and it gets into the following error

Error 530 "Class does not support Automation or does not support expected interface"

According to a web search the following was stated

"Microsoft Data Access Components (MDAC) are normally included with application programs that need them and are installed automatically during the setup process. A problem can occur if the incorrect version of MDAC is included on the installation disk, or if MDAC is already installed on the computer and the setup process does not overwrite MDAC with the new version. When the software references one version of MDAC but a different (usually older) version is installed, Error 430 is the result."
"The best solution is to download and install the latest MDAC version from Microsoft's web site (as 12/05/02, the latest version is 2.6, SP2)"

I had this experience only with win2k and after installing mdac_typ_28sp1.exe, then all is fine. This .exe will not run in xpwin and xpwin already has version 2.8 hence it has always work as it is.

I will be using the component checker "cc.exe" to do a check to see what is really happening from this aspect. Meanwhile if any one has any views, do share. Thanks.

 

[CBrighton]

Open the database on the problem PC.

Press alt&F11 to access VBA window.

Click Tools => References.

Check there are no missing references (.dll files) on that PC which the database is expecting to use.

 

[FuzMic]

Thanks mate

But since i do no have a full version of Access in the problem PC, i can't do you you suggest. Did i get u right?

PS I finally installed a full Access07.SP2 and had a look at the references, all looks fine. But when i try to run the application as .mdb error 430 appear. This is really driving me nuts!.

HELP

 

[Galaxiom]

When does it throw the error? Your error handling probably indicates the procedure name (if you set it up properly).

Turn off the error handling in that procedure by commenting out the OnError GoTo line and run the problem on the mdb. It should then stop on the exact VBA line with the problem. (Or on the line that calls a procedure with a problem)

 

[FuzMic]

Hi Gala good to see you again

With a full version of Access07.sp2, i ran the actual .mdb and found that the error fires on opening a recordset ie rsCom.open .,currentproject.connection, 1, ...

This error occur for all other .mdb that work perfectly on many PC that has varied configuration. It is only this particulary PC xpwin.sp2 that fires this 430 error. Moreover if i install office02.sp3 on the same PC, the 430 error occur again for any .mdb that open a recordset.

Do take note that all references appears to be fine. ComponentChecker shows all reference correctly eg ado is 2.81sp2

Regsvr32.exe "C:\Program Files\Common Files\Microsoft Shared\DAO\DAO360.DLL" & for ado were also done.

I have also replace the 2 component with working copies, namely the DAO360.dll & msado15.dll.

After all these tinkering, i think some registry are missing from the OS. Views appreciated.

 

[Galaxiom]

CurrentProject.Connection is ADO so DAO isn't involved in the problem.

I would suggest you try Late Binding the recordset. It is more reliable where the database is being run on different versions of Windows.

 

[FuzMic]

Thanks mate

I have tried a simple form in a .mdb with fresh reference to to msActiveX Data Object 2.8 Library

The 430 error occur on executing the following

cmd.ActiveConnection = CurrentProject.Connection

cmd was earlier defined with: Dim cmd as new ADODB.COMMAND
With the error it of course did not go to cmd.execute "DELETE * FROM tbl;


I am sure this is a real tell tale sign. Hope you look at it from angle rather than late or early binding. If I use currentdb.execute "DELETE * FROM tbl;", then there is no problem.

 

[Galaxiom]

CurrentProject.Connection is ADO. You are using ADO syntax.

There is no connection string for a DAO recordset. You simply open the recordset against Currentdb (or another database if it is located elsewhere).

Set rsCOM = Currentdb.OpenRecordset (strSQL)

 

[FuzMic]

After understanding abt DAO vs ADO I am still lost in solving what cause the problem!! What is yr final word on this?

 

[Galaxiom]

Try this:

Dim cnn as ADODB.Connection
Set cnn = CurrentProject.Connection
cmd.ActiveConnection = cnn

 

[Galaxiom]

Also wondering why you are using ADO. Normally one use DAO particularly for the CurrentDb unless an ADO capability such as disconnection is required.

 

[FuzMic]

ADO is used in case i need to loop through a series of recordset to manipulate its contents.

DAO is used in case of simple SQL action on an mdb table.

I try yr idea

Dim cmd as new ADODB.command 'added for the 4th line
Dim cnn as ADODB.Connection
Set cnn = CurrentProject.Connection
cmd.ActiveConnection = cnn

Error 430 at set cnn = currentproject.connection

I strongly feel something in WinXP disallow a ADODB connection and it has nothing to do with the syntax or choice of ADO or DAO.

 

[Galaxiom]

ADO is used in case i need to loop through a series of recordset to manipulate its contents.

That can be done with DAO recordsets. You might be able to avoid the issue entirely by changing to DAO.

I try yr idea

Dim cmd as new ADODB.command 'added for the 4th line
Dim cnn as ADODB.Connection
Set cnn = CurrentProject.Connection
cmd.ActiveConnection = cnn

Error 430 at set cnn = currentproject.connection

I strongly feel something in WinXP disallow a ADODB connection and it has nothing to do with the syntax or choice of ADO or DAO.

Clearly the ADO reference is being found since it didn't reject the Dim of the connection object. (That was what I was trying to determine with the suggestion.) The problem may be to do with OLEDB.

Try this, it uses a different OLEDB connector.

Set cnn = CurrentProject.AccessConnection

 

[FuzMic]

Thanks mate for trying to narrowing down to OLEDB. Will revert after testing. Would also try to reinstall JetSP8 for xpWin too, what say you?

On DAO
1 i would imagine that Dim rst As Recordset is DAO; it this correct?
2 i read some years ago that Microsoft is moving on with ADO leaving DAO behind; is this so? What is the one essential pro & con of both?

 

[Galaxiom]

It guess wouldn't hurt to try reninstalling. I am no expert but I guess it depends on where it breaks. You could try an ADO connection to SQL Server and see if that worked. That would perhaps clear the suspicion on VBA itself.

Other applications use OLEDB too without Jet getting involved. It would just be something held in DLLs. Mabe check for anything with OLEDB in the name. Remember too that Access 2007 uses ACE instead of Jet.

Among others I have files in Windows (XP Pro) called: C:\WINDOWS\Installer\$PatchCache$\Managed\00002119130000000000000000F01FEC\12.0.4518\ACEOLEDB.DLL

C:\WINDOWS\Installer\$PatchCache$\Managed\00002119130000000000000000F01FEC\12.0.6425\ACEOLEDB.DLL

Here is a page about the difference between DAO and ADO.
http://allenbrowne.com/ser-29.html

DAO is still with us in Access 2010.

ADO has features suited for database support in ASP. The future of application development is with web styled code so it is certainly something you want to get familiar with if you are intending to continue with a development career.

 

[FuzMic]

Much much appreciate for your effort. Will come back when things get clear up soon - i hope. With cloud processing i am tinkering with php through wamp in windows. Have a good day!

 

[FuzMic]

Gala using cnn = CurrentProject.AccessConnection, same error at this point.

Can't reinstall JetSP8 either as system rejects this installation.

I am running out of fast options!!!

 

[FuzMic]

Galaxiom - One final word on this thread

Thanks to your prompting, I have worked round this problem PC by switching to DAO, result is I to learn to loop through an DAO RecSet. However even though there is no problem with conversion I found that DAO RecSet, compared to ADODB, has 2 constraints
1) For a full recordcount we need to moveLast
2) Each & every encounter with a RecSet requires .Edit closing with .Update to do editing.

Meanwhile i will be testing on the problem PC, an ADODB connection via ODBC and see what happens. I will try similar connections using VB6 .exe and then will probably start a new thread to see if members can pin point a fix to the PC's inability to handle a ADODB.connection.