Access 2007 cannot open Word 2003 docs

[irishtyke]

I have been using an Access database for, among other things, opening Word & Excel documents from a click on a cmd button. I've had no problem in A2000 & A2003, nor do I have a problem in A2007 if the Word & Excel files are also in 2007. When the Word & Excel files are 2000 or 2003 though, I am getting "File not found".

All help or suggestions would be greatly appreciated.

 

[aikea]

You need word to open a word file.

You may see a embeded word file open in Access or Excel, but I can asure you that machine has word installed.

 

[irishtyke]

Many thanks for the response Aikea. The user's system has Access 2007 Runtime with command buttons that are trying to open Word 2003 and Excel 2003 documents. The user's system certainly has Excel 2003 and Word 2003. I am unable to test for compatibility because my development system always uses Access 2007 to open the files successfully. It is as if Access 2007 cannot recognise Word 2003 & Excel 2003.

 

[RoyVidar]

I don't understand what you mean by "trying to open Word 2003 and Excel 2003 documents". Do you mean automation, followhyperlink, shell, ShellExecute or something else?

If you could give us the code or method failing for you, what actually happens..., I think it's a bit easier to assist.

Edit: could it be filetype/format? docx/docm/doc/xlx/xlm/xls?

 

[irishtyke]

Access2007 Runtime cannot find Word2003 & Excel2003 Files

Hi Roy.

Many thanks for your response.

The utility has been successfully using command buttons within MS.Access to open Word & Excel files. I have used a mixture of CreateObject and Shell to open the files. Pre-Access 2007, I have had no challenges.

The utility runs without error when the user's system has:

- Access2000, Word2000 & Excel2000
- Access2003, Word2003 & Excel2003
- Access2003, Word2000 & Excel2000

However, when the user's sytem has:

- Access 2007 Runtime, Word2003 & Excel2003

... the same command buttons produce a "File not found" error when looking for the Word2003 & Excel2003 files.

It might be a comaptibility problem.

Is this description any clearer?

 

[RoyVidar]

Being so secretive with code, it's hard to say, but I can successfully open a 97/2003 format file from Access 2007 through Shell with both Word 2003 and 2007. Same with Excel. Just by changing the path to Office directory (using correct path).

I have no chance testing late binding from Access 2007 to earlier versions of word or excel, but late binding does work here.

I don't have the runtime.

Conclusion:
There might be something wrong with your code, Office installation or the Access runtime. Good luck.

 

[irishtyke]

Access 2007 finding Word 2003

Being so secretive with code, it's hard to say, but I can successfully open a 97/2003 format file from Access 2007 through Shell with both Word 2003 and 2007. Same with Excel. Just by changing the path to Office directory (using correct path).

I have no chance testing late binding from Access 2007 to earlier versions of word or excel, but late binding does work here.

I don't have the runtime.

Conclusion:
There might be something wrong with your code, Office installation or the Access runtime. Good luck.

--------------------------------------------------------------
Hi Roy,

Many thanks, once more, for your response.

In fact, the only way I had been able to overcome this challenge IS, as you also suggest, by specifying the precise path to the OFFICE11 directory. My main challenge was that my users don't all have MSO.2003; some of them have MSO.2000 and some have MSO.2007.

My solution was to build-in to the utility a runtime method for switching the path between the following 3 targets when using the Shell method:

"C:\Program Files\Microsoft Office\OFFICE\"
"C:\Program Files\Microsoft Office\OFFICE11\"
"C:\Program Files\Microsoft Office\OFFICE12\"

The code I used was:

---- CODE STARTS ----
Dim stAppName As String
Dim MSOCode As Integer
'
stAppName = "Winword.exe c:\foldername\" & "filename"
'
If MSOCode = 0 Then
Call Shell("C:\Program Files\Microsoft Office\OFFICE\" & stAppName, 1)
ElseIf MSOCode = 3 Then
Call Shell("C:\Program Files\Microsoft Office\OFFICE11\" & stAppName, 1)
ElseIf MSOCode = 7 Then
Call Shell("C:\Program Files\Microsoft Office\OFFICE12\" & stAppName, 1)
Else
Call Shell(stAppName, 1)
End If
---- CODE ENDS ----

Although this solution is more cumbersome than I had hoped, it seems to work without problem.

One concern I have is that it might not be safe to assume that ALL my users will have the same installation paths as I have assumed, although why they might want to change the default path would be a mystery to me. Do you think I am safe to make this assumption, or should I include a navigation dialogue that enables the user to go hunting for the correct directory? I'm always apprehensive when the user has to do any more than turn on the computer and make the coffee.

 

[RoyVidar]

You could try the ShellExecute API in stead of Shell. This will open the file in the program it is associated with (Edit: without needing to specify full path) - check out the wrapper here http://www.mvps.org/access/api/api0018.htm

 

[irishtyke]

I saw that piece of code when I was first browsing for a solution but, to be honest, I didn't know there was a difference between ShellExecute and Shell.

Anyhow, many thanks for your time and your advice Roy. You have been very helpful.

 

[RoyVidar]

You are welcome!

I think the VB(A) Shell function, is just another wrapper for the ShellExecute API. With the former, you'll need full path/name of the app, in addition to path/name of the file you wish to open. With ShellExecute, you only need the path and name of the file you wish to open.

I stopped using Shell years ago, and use ShellExecute in stead.

 

[irishtyke]

That explains the difference very clearly.

I will accustom myself with ShellExecute for all future amendments and projects.

Many thanks again.

I know I cannot pick your brains on demand but I was intending to start a new thread later asking how to set (fixed) the size of an application's Access window, which is always fine and centred on my development system, but always opens in full screen mode on the user's sytem. Although this doesn't affect the application's operation, it looks ugly, all being squeezed into the top left corner of the user's maximized Access window.