Any way to determine Service Pack level on an Excel install

  • Thread starter Thread starter Doug_F
  • Start date Start date
D

Doug_F

I'd like to be able to run a bit of code on all of my user's workstations to
determine if SP2 is installed. I'm pretty much open to any method that works.

TIA

Doug
 
Application.Build

This is the Build's I have for my 2007 SP1 & SP2 respectively
6331, 6524

My guess is if it's say 6500+ you can be pretty sure it's SP2 (in 2007 of
course), but I'll leave it to you to research if that is indeed the case.
Maybe you might post back your findings!

Regards,
Peter T
 
Interesting observation. I agree the first set of 4 digits correlates to the
Build number.

FWIW I hadn't suggested 6500 was the lower limit, rather as a guess above
that probably confirms SP2, not quite the same thing. However I am now
starting to wonder if the build number even relates to the SP at all, maybe
it doesn't!

Regards,
Peter T

Cosmo said:
I have a similar need, and I found this thread (and forum) in my
search. On the computers I have checked in my office, I am getting 2
different numbers for SP2

12.0.6425.1000 SP2
12.0.6504.5000 SP2

The first set of 4 digits after the version number (12.0) correlates to
the Build number; don't know what the last set of 4 digits signifies.

Has anyone resolved how to determine which numbers (or number range)
distinguishes SP1 from SP2? Since I'm getting 6425, it would appear that
6500 is not the lower limit for SP2 as has been suggested here.


Doug_F;645959 said:
Peter,

Thanks. Off to write some code and trap some data.

Doug
Click to expand...


--
Cosmo
------------------------------------------------------------------------
Cosmo's Profile: 1576
View this thread:
http://www.thecodecage.com/forumz/showthread.php?t=179767

Microsoft Office Help
Click to expand...
 
From your posts and thinking about it more it really seems that app.Build
does not help determine which SP is installed, sorry for introducing the
idea. It got me to thinking along different lines.

In the main SP2 fixes and improves things. However here's an odd bug which,
in limited testing, appears to have been introduced in SP2

=DATEDIF(DATE(2009,6,27),DATE(2012,1,5),"md")

If you get the "wrong" answer 122 it's probably SP2, but if you get the
right answer of 9 it's probably SP1.

Please (anyone) feel free to confirm or otherwise. I'm sure there are other
discrepancies which might be similarly checked but off the top of my head
forget which.

Regards,
Peter T

Cosmo said:
Sorry, didn't mean to imply that the suggestion was based on more than
a guess, should have said something more along the lines of 'as has been
suggested might be the case'

A little more investigating in my office showed a few other details:
I've been checking the Resources panel in PowerPoint and I have found a
few machines that show different results:

My computer and another I checked shows both sets of numbers the same:
Microsoft Office PowerPoint 2007 (12.0.6425.1000) SP2 MSO
(12.0.6425.1000)
These numbers are the same in Excel and Word as well.

On a few computers, the two sets of numbers are different:
Microsoft Office PowerPoint 2007 (12.0.6504.5000) SP2 MSO
(12.0.6425.1000)
Microsoft Office Excel 2007 (12.0.6514.5000) SP2 MSO (12.0.6425.1000)
The number which corresponds with the 'Application.Build' is the first
set of 4 digits in the first group of numbers (before the 'SP2'), and is
different for each Office application.

I wish I knew if this number has any correlation to the SP number; I
feel like I'm making some slight progress, but can't tell if I'm
actually getting anywhere. And I haven't found anywhere that explains
what these numbers mean, and why they are not consistent across our
systems.
Interesting observation. I agree the first set of 4 digits correlates
to the
Build number.

FWIW I hadn't suggested 6500 was the lower limit, rather as a guess above
that probably confirms SP2, not quite the same thing. However I am now
starting to wonder if the build number even relates to the SP at all, maybe
it doesn't!

Regards,
Peter T
Click to expand...
Code Cage Forums'
(http://www.thecodecage.com/forumz/showthread.php?t=179767)

--
Cosmo
------------------------------------------------------------------------
Cosmo's Profile: 1576
View this thread:
http://www.thecodecage.com/forumz/showthread.php?t=179767

Microsoft Office Help
Click to expand...
 
Oh man, this just gets better and better.

I wrote a bit of code that eventually does 'xlApp.Build' and sent it around
for folks to run and log the results into a database.

I have a user who shows the following:
If he looks in Excel at the resources to get the version and build we see:
2007 (12.0.6504.5000) SP2 MSO ( 12.0.6425.1000)
When he runs my little script, I get version 12 and build 6514.

WT#$&&??

I ran into the same problem with a different user, the 'build' after MSO was
something like 6020 but xlApp.Build was 4518.

Does anyone have any idea which way to go?

I guess for us, it may not really matter. We're supposed to be using
software delivery system that pushes the SAME version to EVERYONE. The fact
that we're seeing 4 or 5 different builds may mean that the push software
isn't working as expected or IT has mucked up the package and is pushing
different version which would be out of compliance with our change control
procedures.

I'd like to have some resolution before I start screaming at IT...

Thanks

Cosmo said:
Sorry, didn't mean to imply that the suggestion was based on more than
a guess, should have said something more along the lines of 'as has been
suggested might be the case'

A little more investigating in my office showed a few other details:
I've been checking the Resources panel in PowerPoint and I have found a
few machines that show different results:

My computer and another I checked shows both sets of numbers the same:
Microsoft Office PowerPoint 2007 (12.0.6425.1000) SP2 MSO
(12.0.6425.1000)
These numbers are the same in Excel and Word as well.

On a few computers, the two sets of numbers are different:
Microsoft Office PowerPoint 2007 (12.0.6504.5000) SP2 MSO
(12.0.6425.1000)
Microsoft Office Excel 2007 (12.0.6514.5000) SP2 MSO (12.0.6425.1000)
The number which corresponds with the 'Application.Build' is the first
set of 4 digits in the first group of numbers (before the 'SP2'), and is
different for each Office application.

I wish I knew if this number has any correlation to the SP number; I
feel like I'm making some slight progress, but can't tell if I'm
actually getting anywhere. And I haven't found anywhere that explains
what these numbers mean, and why they are not consistent across our
systems.

Interesting observation. I agree the first set of 4 digits correlates
to the
Build number.

FWIW I hadn't suggested 6500 was the lower limit, rather as a guess above
that probably confirms SP2, not quite the same thing. However I am now
starting to wonder if the build number even relates to the SP at all, maybe
it doesn't!

Regards,
Peter T
Click to expand...
Code Cage Forums'
(http://www.thecodecage.com/forumz/showthread.php?t=179767)

--
Cosmo
------------------------------------------------------------------------
Cosmo's Profile: 1576
View this thread: http://www.thecodecage.com/forumz/showthread.php?t=179767

Microsoft Office Help

.
Click to expand...
 
Turns out, he did the 'resource' check using Word and my code checks Excel.
I'm betting when he tests again in Excel, it will show 6514.

I just checked with my 6020/4518 guy and the 4518 is on the 'left' side and
the 6020 is on the 'right' side, so xl.Build is pulling in data from the left
parenthetical number set.

On my machine (which is at SP2), I show 6525 in both sets of numbers.

So does this help at all? Can I relate any 'build' value with SP2 or is
this a lost cause?

Doug
 
I know my first idea wasn't very good, but don't let that put you off trying
my latest!

in VBA
x = Application.Evaluate("=DATEDIF(DATE(2009,6,27),DATE(2012,1,5),""md"")")

If x = 9 then
sp = 1
elseif x = 122 then
sp = 2

Like I say, only an idea. Maybe you and Cosmo might check it out with your
combination of SP1 & SP2 users....

Regards,
Peter T

Doug_F said:
Oh man, this just gets better and better.

I wrote a bit of code that eventually does 'xlApp.Build' and sent it
around
for folks to run and log the results into a database.

I have a user who shows the following:
If he looks in Excel at the resources to get the version and build we see:
2007 (12.0.6504.5000) SP2 MSO ( 12.0.6425.1000)
When he runs my little script, I get version 12 and build 6514.

WT#$&&??

I ran into the same problem with a different user, the 'build' after MSO
was
something like 6020 but xlApp.Build was 4518.

Does anyone have any idea which way to go?

I guess for us, it may not really matter. We're supposed to be using
software delivery system that pushes the SAME version to EVERYONE. The
fact
that we're seeing 4 or 5 different builds may mean that the push software
isn't working as expected or IT has mucked up the package and is pushing
different version which would be out of compliance with our change control
procedures.

I'd like to have some resolution before I start screaming at IT...

Thanks

Cosmo said:
Sorry, didn't mean to imply that the suggestion was based on more than
a guess, should have said something more along the lines of 'as has been
suggested might be the case'

A little more investigating in my office showed a few other details:
I've been checking the Resources panel in PowerPoint and I have found a
few machines that show different results:

My computer and another I checked shows both sets of numbers the same:
Microsoft Office PowerPoint 2007 (12.0.6425.1000) SP2 MSO
(12.0.6425.1000)
These numbers are the same in Excel and Word as well.

On a few computers, the two sets of numbers are different:
Microsoft Office PowerPoint 2007 (12.0.6504.5000) SP2 MSO
(12.0.6425.1000)
Microsoft Office Excel 2007 (12.0.6514.5000) SP2 MSO (12.0.6425.1000)
The number which corresponds with the 'Application.Build' is the first
set of 4 digits in the first group of numbers (before the 'SP2'), and is
different for each Office application.

I wish I knew if this number has any correlation to the SP number; I
feel like I'm making some slight progress, but can't tell if I'm
actually getting anywhere. And I haven't found anywhere that explains
what these numbers mean, and why they are not consistent across our
systems.

Interesting observation. I agree the first set of 4 digits correlates
to the
Build number.

FWIW I hadn't suggested 6500 was the lower limit, rather as a guess above
that probably confirms SP2, not quite the same thing. However I am now
starting to wonder if the build number even relates to the SP at all, maybe
it doesn't!

Regards,
Peter T


I have a similar need, and I found this thread (and forum) in my
search. On the computers I have checked in my office, I am getting 2
different numbers for SP2

12.0.6425.1000 SP2
12.0.6504.5000 SP2

The first set of 4 digits after the version number (12.0) correlates to
the Build number; don't know what the last set of 4 digits signifies.

Has anyone resolved how to determine which numbers (or number range)
distinguishes SP1 from SP2? Since I'm getting 6425, it would appear that
6500 is not the lower limit for SP2 as has been suggested here.


Doug_F;645959 Wrote:

Peter,

Thanks. Off to write some code and trap some data.

Doug

:

Application.Build

This is the Build's I have for my 2007 SP1 & SP2 respectively
6331, 6524

My guess is if it's say 6500+ you can be pretty sure it's SP2 (in
2007 of
course), but I'll leave it to you to research if that is indeed the
case.
Maybe you might post back your findings!

Regards,
Peter T



I'd like to be able to run a bit of code on all of my user's
workstations
to
determine if SP2 is installed. I'm pretty much open to any method
Click to expand...
Code Cage Forums'
(http://www.thecodecage.com/forumz/showthread.php?t=179767)
'Microsoft Office Help' ("http://www.thecodecage.com")
Click to expand...


--
Cosmo
------------------------------------------------------------------------
Cosmo's Profile: 1576
View this thread:
http://www.thecodecage.com/forumz/showthread.php?t=179767

Microsoft Office Help

.
Click to expand...
Click to expand...
 
Oh, this is cool.

If I paste the formula below into an Excel cell, I get 173.

When I try and look up DateDif in excel Help, it doesn't exist.

If '9' is the right answer, and SP2 gives 122, what the heck do I have?

I'm really glad it's Friday.

In the main SP2 fixes and improves things. However here's an odd bug which,
in limited testing, appears to have been introduced in SP2

=DATEDIF(DATE(2009,6,27),DATE(2012,1,5),"md")
 
OK forget that idea then (fwiw the correct answer is 9, but DateDif is
buggy)

As I said before, I'm almost sure there are other differences in behaviour
between SP1 & SP2 that would help identify, just don't recall at the moment.

Regards,
Peter T
 
I found a site via Google that describes DateDif - it's been in Office for a
while but only ever 'exposed' via help or the formula editor in one version
so at least I get that piece.

The site also described how DateDif works. If I understand correctly, when
using the "md" option, it means 'take the difference in days between the two
dates entered and pretend they happen in the same month and year'.
(http://www.cpearson.com/excel/datedif.htm)

The difference between the 5th and 27th isn't 9 days but 22. So 9, 122, and
173 are all 'wrong'. I probably don't understand how DateDif works so
correct my assumptions if wrong.

I've been looking all over the web and an not finding any clear indicators
of whether SPs are part of builds or not. If I find the Rosetta stone, I'll
post back.

Dontcha love a good mystery?

Doug
 
I found a site via Google that describes DateDif - it's been in Office for a
while but only ever 'exposed' via help or the formula editor in one version
so at least I get that piece.

The site also described how DateDif works. If I understand correctly, when
using the "md" option, it means 'take the difference in days between the two
dates entered and pretend they happen in the same month and year'.
(http://www.cpearson.com/excel/datedif.htm)

The difference between the 5th and 27th isn't 9 days but 22. So 9, 122, and
173 are all 'wrong'. I probably don't understand how DateDif works so
correct my assumptions if wrong.

I've been looking all over the web and an not finding any clear indicators
of whether SPs are part of builds or not. If I find the Rosetta stone, I'll
post back.

Dontcha love a good mystery?

Doug
Click to expand...

DateDif is present but undocumented except in, I believe, XL 2000.

Also, it is partially broken since Excel 2007 SP2 and many have noted the
erroneous answers you receive with certain arguments.

From an old posting:

You might want to reconsider using the DATEDIF function. It is an
undocumented (and, thus, probably an unsupported) Excel function which
appears to be broken in XL2007 at Service Pack 2. Someone recently posted
this message as part of a newsgroup question...

**********************************************************************
=DATEDIF(DATE(2009,6,27),DATE(2012,1,5),"md")

In 2007, this gives me 122. This happens all the way up to the point
where the second date is 1/26/2012 and then it hits zero at 1/27/2012.
In 2002, however, it gives me the correct answer of 9.
--ron
 
No it should be 9, ie between the 27th to the 5th (might be 8 or less if the
month before the 2nd date is not 31 days).

Try this one
=DATEDIF(DATE(2009,6,30),DATE(2009,7,1),"md")
the correct answer is 1
or this one
=DATEDIF(DATE(2009,6,27),DATE(2009,7,5),"md")
correct answer is 8 because the month before July has 30 days (Dec before
Jan has 31, hence 9)

AFAIK DateDif has always worked fine in 97-2003, but at some point in 2007
it became buggy with one or two odd cases, such as the one I mentioned (but
now not sure if SP1 is always correct)

However the result should *never* be more than 30 !

Regards,
Peter T
 
Good find Cosmo!
Looks like my very first suggestion was right after all. Well almost,
instead of my guess of 5000+ it should be 6425+ confirms SP2


Sub test()
Dim nVer As Long, nSP As Long

Call AppInfo(nVer, nSP)
MsgBox "Excel " & nVer & " SP " & nSP

End Sub

Sub AppInfo(nVer As Long, nSP As Long)
Dim nBld As Long

nVer = Val(Application.Version)
nBld = Application.Build

nSP = 0

Select Case nVer
Case 14: 'to be updated after first SP

Case 12 ' 2007
If nBld >= 6425 Then
nSP = 2
ElseIf nBld >= 6214 Then
nSP = 1
End If

Case 11 ' 2003
If nBld >= 8173 Then
nSP = 3
ElseIf nBld >= 7969 Then
nSP = 2
ElseIf nBld >= 6355 Then
nSP = 1
End If

Case Else
' extend with info from these links

' 2007 http://support.microsoft.com/kb/928116
' 2003 http://support.microsoft.com/kb/821549
' 2002 http://support.microsoft.com/kb/291331
' 2000 http://support.microsoft.com/kb/255275
End Select

End Sub

Other Office apps also in the above links.

Regards,
Peter T
 
Good find Cosmo!
Looks like my very first suggestion was right after all. Well almost,
instead of my guess of 5000+ it should be 6425+ confirms SP2
Click to expand...
<snip>

Typo, should read -
instead of my guess of 6500+ it should be 6425+ confirms SP2

Peter T
 
Interesting but not helpful, according to this in the 2nd link

"Last point: once a product ships, the rules for build numbers become even
more complicated and different. So, if you have Service Pack 2 for Office
2003, you might see a nonsensical number like 6552 or something. Don't
worry about it, it's not tied directly to a date in the same way anymore."

IOW, don't read anything into the build numbers other than documented.

Regards,
Peter T
 
Back
Top