My Journal

RG Roofing

218 Church St. South Amboy, NJ 08879

Specializing in all types of roofing.
Replacement windows, doors & gutters.
Siding, decks, kitchens, baths & all interior renovations

Free Estimates

Richie
Ph. 732-721-3431
Cell. 908-217-6025

Heard he had heart attack so now his kaki doing all the work. Joe said try a few prices from various.

A Windows 10 machine cannot open some function of a 2007 Access database. Giving the above error. This appears to have something to do with VBA > Tools > References pointing to Microsoft Word 12.0 Object Library vs. Microsoft Word 16.0 Object Library.

Solution:

Removed all MS Office in the Win10 machine. Installed MS Office 2016 (32-bit, since the original was 32bit), which changes all machines' access to the database to point to the new reference: Microsoft Word 16.0 Object Library, causing some errors since the 2007 version couldn't handle 2016 one (the fix is easy, just go in to the references and change it to the right MS Word object library version, but this has to be done every time manually whenever the other version from another machine use the database and thus changed the library version), so I installed MS Office 2007 again on top of the 2016 version. The system automatically defaults office apps, including reference library to 2007 version instead of the 2016 version. And this time, the 2007 on Win10 works great with all features of the database. I will not remove the 2016 version for now, too lazy to deal with it testing it without the 2016 version at this point.

Update 1/24/2023:

Maybe I could still get a better fix by figuring out what (could be DAO vs. ACE) was deprecated and add those features back, but then we would be stuck at Office 2007. It's time to move on. Since I've already updated some Access VBA scripts to be compatible with the higher versions (i.e. revise LCase to VBA.LCase instead, etc.), I believe that the old database is compatible with the 2016 client. The only thing I need to watch out for is not letting version 2016 to dominate and save the VBA references (as mentioned above), one way to do this is to keep the DB open on the server so others won't have exclusive rights to mess with it.

So the final solution is this: use Office 2016 for these All-in-One Dells. Use KMSpico if necessary. Works fine now...for now.

Update 3/10/2023:

Finally found the solution for this. I pastes the solution from the site here below:

Microsoft Access and Outlook Integration - 48 Error in Loading DLL

A customer with a 3rd party developed Access database/application ran into this issue with some new computers. These were running 64 bit Windows 7 and 32 bit Office. The specific task was trying to open a new email in Outlook from Access.

While the error was 48 Error in loading DLL the problem had nothing to do with DLLs. It ended up being that because the computer was preloaded with Office 2016 (trial version, from Dell), when uninstalled it left some garbage behind in the registry. After running Procmon and finding out what it was trying to do, it wasn't too hard to find and fix.

The solution in the end was to delete the registry key (and subkeys):

HKEY_CLASSES_ROOT\TypeLib\{00062FFF-0000-0000-C000-000000000046}\9.6

Obviously make a backup of this key before deleting, but this did the trick for all affected computers.

The first registry key suggested above apparently weren't enough as the NYGC Student Access Database still gives the same error when clicking on the Class Registration Form button in Class Registration to open up MS Word template for auto-fill. So I ended up deleting a bunch of "office16" keys in HKEY_CLASSES_ROOT\TypeLib\* by doing F3, until I got tired of searching, seems to be so many of them, and I decided to test it out and voila! It works!!!

So with my school database that generates a word document for Final Report for students, it hit a wall with narrative/comments from teachers that's over 255 characters long. Instead of complaining long winded commentaries, I just had to fix this.

The best solution page, that is thorough enough, I am pasting its content here, lest it's taken down: (I basically just used ActiveDocument.Bookmarks("Bookmark1").Range.Text Instead of .FormFields("Bookmark1").Result.

Lynn,

I think if you have a better understanding of what's happening in Word
you'll be better able to come up with an acceptable solution.

First, you are correct that the character limit for formfields is 255. In
addition, you can set the .Result property of a formfield without removing
the protection from the document using something like:

ActiveDocument.FormFields("Text1").Result = "This is a string of less than
255 characters."

This is the basic nature of forms protection: the only place you can add
content to the forms-protected sections of the document is the formfields
within the section.

However, as you have found, if the content to be added exceeds the 255
character limit, setting the .Result property of the formfield doesn't work.
In this instance, you have a few options available to you. You can:

* Use the Trim function to truncate the string at 255 characters. This is
probably not an acceptable solution since you undoubtedly want the whole
string to appear in your document.

* Use multiple formfields and the Mid function to parse the string into
255 character "chunks", which then get inserted into various formfields using
the .Result property as described above. Again, this is a less-than-optimum
solution because it's clunky and may not produce an especially attractive
result.

* Use a bookmark and something like the following to insert the text:

ActiveDocument.Bookmarks("Bookmark1").Range.Text = "A long string of more
than 255 characters."

However, as you have discovered, this method requires the section containing
the bookmark to be unprotected (for the reasons discussed above), and you
have stated that making this section unprotected is not an option.

The best solution is to unprotect the document prior to inserting the text
and then reprotecting it again afterwards. The code for doing this would look
something like:

ActiveDocument.Unprotect "password"
ActiveDocument.Bookmarks("Bookmark1").Range.Text = "A long string of more
than 255 characters."
ActiveDocument.Protect wdAllowOnlyFormFields, True, "password"

(See the Word VBA help topics on document protection for more information on
this code.)

Only one thing concerns me: You say that you are "pushing" data from Excel
into Word. This makes me think that you are driving this process from the
Excel side rather than from Word. I'm not quite sure if you will be
successful in trying to unprotect a Word document using code from within
Excel. This being the Word VBA forum, I suspect that most contributors would
take the approach of "pulling" data from Excel using code in Word - and thus
would not have to worry about this potential problem. However, some of us do
"cross over" so maybe someone else will be able to help you with this
possible sticking point. Otherwise, I can only suggest that you ask the
question in the Excel VBA forum.
--
Cheers!
Gordon