views:

396

answers:

2

This does NOT work:

Sub X()
    Dim A As Access.Application
    Set A = CreateObject("Access.Application")
    'Do Stuff
End Sub

However, this DOES work:

Sub X()
    Dim A As Object
    Set A = CreateObject("Access.Application")
    'Do Stuff
End Sub

I know they do virtually the same thing, but can anyone tell me how to make an access.application object? I should add that I have Crystal Reports 11 and on my last upgrade, it may have 'unregistered' some VBA DLLs.

(Update 2009-06-29)

In response to the first 2 questions, I am using MS Access VBA to control some other Access & Excel files. Since this will only ever run on my local machine, I can guarantee that Access will always be installed. I have also referenced the "Microsoft Access 11.0 Object Library" (MSACC.OLB).

I know there's ways around this, i.e. use early binding when coding, and switch to late binding when running it, I just don't understand why the early binding method doesn't work at all on my machine (Of course, the code works fine on another machine with Access).

+3  A: 

If you are writing this in Access there is no need to do that as the Application object is already there for you. If you are writing this in Excel or Word then you need to add a reference to the Access Library. Go to Tools/References and look for Microsoft Access XX Object Library

DJ
No, you don't need a reference to the Access library, and you'd be better off without it, as the original poster was doing it. In Excel, without the reference, Excel VBA knows nothing about the Access.Application data type, and that's why it can't work.
David-W-Fenton
If you want intellisense and early binding that you do. I usually do both - I add the reference while coding and the change it back to a general object later for late-binding.
DJ
Typically, you won't know for sure that the target machine will have Access installed; if it doesn't an you have used early binding (i.e. set a reference) then the user will receive a compile error and your application will not run. That's why David said you are better without it i.e. better to use late binding (i.e. CreatObject) then test whether Access exists at run time and handle it gracefully. You can code with early binding (for intellisense etc) then switch to late binding for deployment, of course.
onedaywhen
A: 

Hello,
The code that you say is not working is legal syntax. What error are you getting? When does it occur? Do you know the line of code it happens at?

Just as a side note, this is legal syntax as well:

    Dim accApp As Access.Application
    Set accApp = New Access.Application

But to be clear, the CreateObject Syntax is legal and not the source of the problem.

Oorang
(Original Poster here). I get a "error loading DLL" message when I try either the createobject method or the new access.application method. (Oh, and I'm using VBA in Access).
PowerUser
do you have more than one version of Access? Do you have the full version or just the runtime? Which OS?
Oorang
Oorang, I have Access 2003 upgraded from Access 2000 (full version) running on a standard XP box. I suspect it is my Crystal Reports upgrade that damaged my registry, but I don't know how to begin checking this.
PowerUser
If you are in a big company with an IT dept, I'd just ask them to reimage your machine. If you are on your own, then you might want to try reregistering the components with RegSvr32. Another thing to verify is check the project references to make sure none are showing with broken references. (It'll be easy to tell, they say "MISING" in all caps.)
Oorang
(gee Orang, you sure do get around!)Unfortunately, my IT dept. is overwhelmed these days and asking them to reimage/rebuild my machine would just cost me alot of political capital. I'll just reregister the components and cross my fingers.
PowerUser
....Get around?
Oorang