Error from Office 2000 to Office XP

[NQuinn]

I loaded an access application, which was created and runs fine on Office
2000, onto a computer with Office XP. The application creates a run-time
error when running a procedure that creates a new Excel Object. I looked at
the references and the only difference I can find is that on the computer
with 2000 the references is:

Reference: Excel
Location: C:\Microsoft Office\Office\E XCEL9.OLB

on the XP computer the reference is:

Reference: Excel
Location: C:\Microsoft Office\Office10 \EXCEL.EXE

Can anyone help me solve this issue?

Thanks in advance for any help.

[Fletcher Arnold]

"NQuinn" <nq****@iciinc. com> wrote in message
news:10******** *****@corp.supe rnews.com...

I loaded an access application, which was created and runs fine on Office
2000, onto a computer with Office XP. The application creates a run-time
error when running a procedure that creates a new Excel Object. I looked at the references and the only difference I can find is that on the computer
with 2000 the references is:

Reference: Excel
Location: C:\Microsoft Office\Office\E XCEL9.OLB

on the XP computer the reference is:

Reference: Excel
Location: C:\Microsoft Office\Office10 \EXCEL.EXE

Can anyone help me solve this issue?

Thanks in advance for any help.

Your're almost there. When you transfer the database to the new machine,
the first thing you should do is to try and compile it - view any code and
chose Debug>Compile. I guess, it will fail on a line like

Dim xlApp As Excel.Applicati on

saying that user-defined type is not defined. When you look at your
refeneces you will see a missing reference to the Excel 9 object library.
Remove this reference and check the box Microsoft Excel 10.0 Object Library
which according to you seems to be in "C:\Microso ft
Office\Office10 \EXCEL.EXE" (whereas on mine it is C:\Program Files\Microsoft
Office\Office10 \EXCEL.EXE). Now try again to compile it and hopefully it
will compile without complaint - If so that's it.

If I am distributing applications to clients I avoid this problem by not
making a reference to any particular version. This is called late binding
as opposed to what you have here - early binding which can cause trouble.
You can search Google for more on this if you are interested in modifying
the code to use late binding.
Fletcher

[NQuinn]

Thanks for your help. I'm trying this. Is it correct to Dim all my
workbook, worksheet and range variables as "Object"?

"Fletcher Arnold" <fl****@home.co m> wrote in message
news:c0******** **@sparta.btint ernet.com...

"NQuinn" <nq****@iciinc. com> wrote in message
news:10******** *****@corp.supe rnews.com...

I loaded an access application, which was created and runs fine on Office 2000, onto a computer with Office XP. The application creates a run-time error when running a procedure that creates a new Excel Object. I looked

at

the references and the only difference I can find is that on the

computer with 2000 the references is:

Reference: Excel
Location: C:\Microsoft Office\Office\E XCEL9.OLB

on the XP computer the reference is:

Reference: Excel
Location: C:\Microsoft Office\Office10 \EXCEL.EXE

Can anyone help me solve this issue?

Thanks in advance for any help.

Your're almost there. When you transfer the database to the new machine,
the first thing you should do is to try and compile it - view any code and
chose Debug>Compile. I guess, it will fail on a line like

Dim xlApp As Excel.Applicati on

saying that user-defined type is not defined. When you look at your
refeneces you will see a missing reference to the Excel 9 object library.
Remove this reference and check the box Microsoft Excel 10.0 Object

Library which according to you seems to be in "C:\Microso ft
Office\Office10 \EXCEL.EXE" (whereas on mine it is C:\Program Files\Microsoft Office\Office10 \EXCEL.EXE). Now try again to compile it and hopefully it
will compile without complaint - If so that's it.

If I am distributing applications to clients I avoid this problem by not
making a reference to any particular version. This is called late binding
as opposed to what you have here - early binding which can cause trouble.
You can search Google for more on this if you are interested in modifying
the code to use late binding.
Fletcher

[Fletcher Arnold]

"NQuinn" <nq****@iciinc. com> wrote in message
news:10******** *****@corp.supe rnews.com...

Thanks for your help. I'm trying this. Is it correct to Dim all my
workbook, worksheet and range variables as "Object"?

Yes - If you want to use late binding. The advantage being that you do not
have to worry about what version of Office is installed. This is very
useful if you distribute your application to people who may upgrade their
version of Office or may use different versions. **It may not be worth it
for you.** It might be simpler just to change your references since early
binding does have some advantages:
Code executes faster - but I have not found the speed improvement to be
worth it.
You can use intellisense - but I write the code using early binding so when
you type "wdApp.", you get a very handy dropdown list of the properties and
methods of the Word.Applicatio n object. I then make the minor amendments to
the code to use late binding, then remove the reference.

Another important note: If you switch to late binding you will not be able
to use the built-in constants. That is, you will have to re-define them
yourself. You cannot simply write:

wdCell.Range.Pa ragraphFormat.A lignment = wdAlignParagrap hRight

because wdAlignParagrap hRight is constant defined by the Word object
library, unless you wrote:

const wdAlignParagrap hRight = 2
Here is an example of some late-binding code which I posted earlier today:
Private Sub PrintWord(strPa th As String)

On Error GoTo Err_Handler

Dim wdApp As Object
Dim wdDoc As Object

Set wdApp = CreateObject("W ord.Application ")

Set wdDoc = wdApp.Documents .Open(strPath)

wdDoc.PrintOut False

Exit_Handler:

On Error Resume Next

wdDoc.Close

Set wdDoc = Nothing

wdApp.Quit

Set wdApp = Nothing

Exit Sub

Err_Handler:
MsgBox Err.Description , vbExclamation, "Error No: " & Err.Number
Resume Exit_Handler

End Sub