Kallal Word Merge in Access 2013

[WrHn85]

Hi,

Can someone help me figure out what in the heck is going wrong with my Super easy word merge???

I've used it successfully for 8 yrs in an Access2003 db.
However, now we're on Access 2013 and I can't get it to work.All the same objects and modules have been copied over to my new blank db.

First tried my existing code opened with Access 2013, works great but not when copied into an accdb created in 2013.

Tried the slightly newer version on Albert Kallal's website.

Also tried the more recent module code for WordCode found in this forum at http://www.access-programmers.co.uk/forums/showthread.php?t=222631


2 issues:
1) On the Contacts form, when clicking either Merge all records or Merge single record this line fails:

Dim OneField As DAO.Field ' dao code
with error message: 'User defined type not defined'


2) This one isn't a deal breaker but looks scary for the end users. There is a new warning msg when an older db successfully opens the Word doc in an older db (using Word/Access 2013), about 'did you know this is going to run SQL: "SELECT __ from O:\Dev\InvDb\__ Data from your database will be placed in the document" etc etc'

If you click Yes on that msgbox, the doc blinks a couple of times, displays merge fields and then displays the values as expected from the SQL.

Any help you can offer would be very much appreciated!

WrHn85

 

[jdraw]

1) It sounds like you are missing a reference to

Microsoft DAO 3.6 Object Library

 

[WrHn85]

Thanks! I had checked that in the previous versions but clearly missed it in my new blank db. But it won't allow me to add it. I found it in "c:\Program Files (x86)\common files\microsoft shared\dao\dao360.dll" and also tried Allan Browne's tip to unregister & re-register it, but still says 'error loading dll'.

Maybe I should just use an mdb instead. Users can still open them within Access 2013.

If anyone has any suggestions about the DAO 3.6 library or how to convert these modules, that would also be useful.
Thanks.

 

[gemma-the-husky]

I presume the library is different in A2013. Maybe you no longer need the dao. reference at all. Leave it off, and see if that works.

just

Dim OneField As Field

 

[Albert D. Kallal]

Actually, since Access 2007, we do NOT need a DAO reference.

JET has been replaced with a new version called “ACE”.

By default the DAO reference should not be checked, and not be used and in most cases will not be checked if you create a new blank database.

So for Access 2010, you use

Microsoft Office 14.0 Access database engine Object

And for Access 2013, you use:
Microsoft Office 15.0 Access database engine Object

There should be no need for a DAO reference, and the above replaces that reference.

Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

 

[WrHn85]

Thanks to both of you. I did try removing the 'DAO.' part of the code, which it didn't like, and also checked to see if Microsoft Access 15.0 Object Library is checked, which it is. Same error occurs when clicking either Merge all records or Merge single record, this line fails:

Dim OneField As DAO.Field ' dao code
with error message: 'User defined type not defined'

We found out today that most new devices purchased for this department will not support 64-bit Office, which is the version I'm using that's giving all the errors. So some users will have 32 and others 64. Doesn't seem like it's going to play nicely.

 

[Albert D. Kallal]

Actually, you do NOT want to change nor remove the DAO prefix in your VBA code (doing so will make things WORSE and more difficult to tell if you have messed up references).

All of your existing DAO code, even code going back to Access 97 should continue to run in 2013. The ONLY change I am suggesting here is to NOT use the DAO 3.6 reference. This has been replaced by the new ACE engine reference.

So I am not suggesting in ANY way to modify the last zillion years of your VBA code and you don’t need to nor should you have to.

Thus there is certainly no need to modify existing code, and that include the word merge code - it still works fine and works unchanged for the last 15 years.

I should point out that developers often “optionally” included the DAO prefix in their VBA variable definitions. I STRONG suggest one continue this habit, since without the prefix your code may well compile but would be VERY MESSED UP due to bad reference issues.

The DAO prefix is optional as it been for the LAST TWENTY or more years of access. As stated it continues to be a rather ok and a good programing practice to use the DAO prefix.

If your VBA code cannot compile, then some other reference is missing or there are some additional ones that need to be removed.

You do NOT want to start messing around with code and wasting your time – such re-coding has NEVER had to be done in the last 20 years of Access and this situation HAS NOT changed for 2013.

Get your code compiling, ensure that code with the DAO prefix ALSO compiles. If such code does not compile, then fix the reference and do NOT go on a wild goose chase and start modifying perfectly good VBA code that been running for years and years.

Modifying existing good existing code will only serve to introduce new issues and bugs – bugs and issues that in typical applications likely been fixed by you over the years.

>15.0 Object Library is checked
I did not say anything about that library (it will and should be included).
You need to remove the DAO reference and ensure that the database engine reference is selected as outlined in my previous post.

Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

 

[Albert D. Kallal]

As for using x64 bit version of office. That is not currently recommend (using x32 office on BOTH x32 and x64 machines is what everyone been doing since windows 7 came out). And having a mix of x64 and x32 office is going to be a source of HUGE issues

The word merge code should run just fine on x64 bit office, but any use of ActiveX and any VBA code that calls windows API code will have to be modified.

So right now, it quite standard and recommend to run x32 office on x64 windows like everyone been doing many years now.

However, if your VBA code has no ActiveX and no API code, then you can adopt office and access x64. Keep in mind that if you use a accDE (or mde), then you have to compile a x64 bit version of your accDE for machines running x64 office, and compile another version for those running x32 office. So you need a test mule or virtual system setup to support both versions of office and have both versions of Access available for deployment if you use compiled applications with Access. And keep in mind you cannot install x32 and x64 (same version) of office on the same computer.

If you use accDB (non compiled Access application), then the VBA source code is available, and such applications can run on both flavors and should re-compiled on demand (automatic). I do still suggest a de-compile of the application when switching between the two flavors of Office however.

So your challenges right now are likely more the x64 bit version of office. If your going to run a mixed environment of x32 and x64 office, you indeed have many HUGE challenges ahead of you. You need to run all x64, or all x32 office. A mix of both types in an organization is going be a significant source of pain and costly IT support dollars.

Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

 

[WrHn85]

OK, I see where I went wrong re: that reference detail. With the new engine selected that line of code no longer fails. Thanks for also explaining the why of it and the x64/x32 options, very much appreciated!

 

[smig]

I think this post is important enough to be sticky