Access 2016 issue

[MW4]

I have code that opens an access database and inserts data. I am moving from Access 2003 to 2016.

The following line is erroring out with 1129: OleInitiate: Initiate failed

Access = ObjectOpen("Access.Application")


Is there anything special about using 2016?
I am also changing machines from 32 to 64 bit OS, but office remains 32 bit.

Any ideas?

[td]

Have you used the WIL Type Viewer to determine if the Access object is even available on the system?   Are you using Office 360 instead of stand alone office?  Are you using an old version of WinBatch on a newer version of Windows?  Have you checked the wwwbatch.ini file for additional error information?

[MW4]

Type Viewer never used it before but it shows access.application.15 says unable to find a type library


365, yes but it is installed and runs locally

newest 2017 Winbatch

no on the ini file, where is it located?

[MW4]

how can I use ADODB to substitute?
ADODB, doesn't error out but it does on the next line: Access.OpenCurrentDatabase(dbname)

Code (winbatch) Select Expand


dbname = "\\flee\FTl\Data\BED\ToOds.mdb"
Access = ObjectOpen("ADODB.Connection");  INSTEAD OF ("Access.Application")
Access.OpenCurrentDatabase(dbname)
Access.Visible = @TRUE
db = Access.CurrentDb

rs = db.OpenRecordset("tblInvoices")


[MW4]

Actually I don't care between access.application and ADODB, I just need this fixed ASAP

[td]

Type Viewer never used it before but it shows access.application.15 says unable to find a type library

Just press the "Yes" button on the dialog that tells you that it can't find the library.  Some objects don't have a separate library do you have to create an instance of the object to get the type information directly.  Access has never had a separate type library so that is nothing new.  What would be instructive is what happens when you press the "Yes" button.

The WIL Type Viewer is a handy tool. You should keep it in mind the next time you use WinBatch with COM Automation.

newest 2017 Winbatch

On which version of Windows?

no on the ini file, where is it located?

Since Windows Vista's release back in 2007 it is in  "{sysdrive}:\users\{your username}\Appdata\Roaming\WinBatch\Settings\"

[td]

how can I use ADODB to substitute?
ADODB, doesn't error out but it does on the next line: Access.OpenCurrentDatabase(dbname)

Code (winbatch) Select Expand


dbname = "\\flee\FTl\Data\BED\ToOds.mdb"
Access = ObjectOpen("ADODB.Connection");  INSTEAD OF ("Access.Application")
Access.OpenCurrentDatabase(dbname)
Access.Visible = @TRUE
db = Access.CurrentDb

rs = db.OpenRecordset("tblInvoices")


The WIL Type Viewer doesn't show that there is such a thing as a "OpenCurrentDatabase" method for the "ADODB.Connection" object ( at least not for the version of ADODB on my system.)  Based on this fact the method is part of the Access programming model but not part of the ADODB model.  You might want to consider looking at the ADODB examples in the Tech Database.

Depending on your version of Windows you may be having a permissions problem with the Access object.  Or it could be that you simply need to include the version number in your Access progid ("Access.Application.15") as MSFT on rare occasions doesn't register a version independent progid for their products.

[MW4]

I'm in Windows Server 2016 Standard

INI file is blank.

Type viewer when I click yes on Access.Application.15 says Object not found. Please try a different ProgID or Classid

[stanl]

You might consider upgrading your .mdb file to .accdb, especially with Office 2016. I have Office 2016 on my Surface and have no issues with my version of WB using ADO (the ACE Provider). I just got the latest WB version which I will install and see if there are any issues - which I sincerely doubt there will be. Then there is always regedit to look for the Access ProgID installed.  And if you do update to .accdb we can help with the proper connect string.

[td]

I'm in Windows Server 2016 Standard

INI file is blank.

Type viewer when I click yes on Access.Application.15 says Object not found. Please try a different ProgID or Classid

Access COM Automation objects are either not installed on the system or are blocked for the account you are using to run the script.  More likely than not the former but the latter is always possible.

Listen to Stan.  He wrote a good number of the ADODB examples in the Tech Database. 

[td]

It appears that until very recently Access was not included in Office 365 business versions unless you got the most expensive, top of the line, Enterprise E3 addition.

[MW4]

I do have E3.

How can I install those com objects.

I'm running as Administrator, so Permissions shouldn't be an issue

[td]

Not that I am saying that it is the problem but running as an admin can be a permissions issue.   It has to do with integrity levels.

If the Access COM Automation server is actually not installed, you will have to search MSFT's site for a way to install them.  I don't use Office 365 and don't have the patients to wade through the marketing drivel - the Office 365 documentation focus on using REST API's to access cloud based storage.

Here is a link to the Office 365 object model.  It might be a place to start.

https://msdn.microsoft.com/en-us/vba/access-vba/articles/accessobject-object-access

[MW4]

I FOUND THE ISSUE!!!

Many thanks to you for pointing me in a direction to look.

Found the solution here:

Fixing the Microsoft Windows Common Control Library (MSCOMCTL.OCX) Security Update
http://www.fmsinc.com/MicrosoftAccess/Controls/mscomctl/