Hi all,
I run MDAC Component Check on my SQL Server 2000. None
of the versions of MDAC passed the tests. The closest one
is 2.7 SP1 (2.71.9030.9) with only One error on
msjtes40.dll file
msjtes40.dll,Error,Field 'FileVersion' mismatch:
Expect '4.00.2927.8' Got '4.00.5914.0',Microsoft Jet
Expression
Does this mean that I have to install 2.71 Service
Pack 1 Refresh: mdac_typ.exe ?
What files contain in this mdac_typ.exe? Would
installing this file help on Memory Leak?
Thank you sooooo much!!!
P.S.: I think I install 2.7 SP1 via Windows Update. I
didn't apply SQL Sever 2000 SP3 at all.
AnnieThat file almost always checks different, so don't worry.
normally if the version number is higher compared to the closest match it is
OK.
This normally happens because you installed some software with an newer DLL.
( I am assuming msjtes40.dll is installed by MS Office, since I always see
it being different at work.)
Tim S
"Annie" <piyomeme@.yahoo.com> wrote in message
news:05da01c34d8b$f0e63f00$a101280a@.phx.gbl...
> Hi all,
> I run MDAC Component Check on my SQL Server 2000. None
> of the versions of MDAC passed the tests. The closest one
> is 2.7 SP1 (2.71.9030.9) with only One error on
> msjtes40.dll file
> msjtes40.dll,Error,Field 'FileVersion' mismatch:
> Expect '4.00.2927.8' Got '4.00.5914.0',Microsoft Jet
> Expression
> Does this mean that I have to install 2.71 Service
> Pack 1 Refresh: mdac_typ.exe ?
> What files contain in this mdac_typ.exe? Would
> installing this file help on Memory Leak?
> Thank you sooooo much!!!
> P.S.: I think I install 2.7 SP1 via Windows Update. I
> didn't apply SQL Sever 2000 SP3 at all.
> Annie
>|||Thank you, Tim.
I don't have MS Office installed on Server, but it could
be something else.
That was helpful. Thank you~
Annie
>--Original Message--
>That file almost always checks different, so don't worry.
>normally if the version number is higher compared to the
closest match it is
>OK.
>This normally happens because you installed some software
with an newer DLL.
>( I am assuming msjtes40.dll is installed by MS Office,
since I always see
>it being different at work.)
>Tim S
>
>"Annie" <piyomeme@.yahoo.com> wrote in message
>news:05da01c34d8b$f0e63f00$a101280a@.phx.gbl...
>> Hi all,
>> I run MDAC Component Check on my SQL Server 2000.
None
>> of the versions of MDAC passed the tests. The closest
one
>> is 2.7 SP1 (2.71.9030.9) with only One error on
>> msjtes40.dll file
>> msjtes40.dll,Error,Field 'FileVersion' mismatch:
>> Expect '4.00.2927.8' Got '4.00.5914.0',Microsoft Jet
>> Expression
>> Does this mean that I have to install 2.71 Service
>> Pack 1 Refresh: mdac_typ.exe ?
>> What files contain in this mdac_typ.exe? Would
>> installing this file help on Memory Leak?
>> Thank you sooooo much!!!
>> P.S.: I think I install 2.7 SP1 via Windows Update. I
>> didn't apply SQL Sever 2000 SP3 at all.
>> Annie
>
>.
>
Showing posts with label component. Show all posts
Showing posts with label component. Show all posts
Friday, March 30, 2012
MDAC Madness
Greetings,
On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
server? Very confusing. Will someone help me get my head around this?
Further, when I set the Component Checker to perform analysis against a
selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
8.50.2162.0 is expected. Is this also anything to be concerned about?
Thanks,
Tim ==Tim,
You don't mention the level of SQL2000 that you are running? Is it SP4?
Chris Wood
<tim@.tcsys.com> wrote in message
news:1123081469.455549.23850@.f14g2000cwb.googlegroups.com...
> Greetings,
> On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
> reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
> MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
> server? Very confusing. Will someone help me get my head around this?
> Further, when I set the Component Checker to perform analysis against a
> selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
> inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
> 8.50.2162.0 is expected. Is this also anything to be concerned about?
> Thanks,
> Tim ==
>|||Thanks for replying, Chris.
I know almost nothing about SQL server, but, that being said, I'm an
otherwise competent MS net admin.
This particular box has an MSDE engine installed by an not-profit
financial application. The management of this app is hands-off, under
the control of the vendor.
The thing is, the same server is also our Backup Exec box. Backup Exec
was configured to use the same SQL instance as the financial app.
That's not unusual; the use of an existing SQL or MSDE instance on the
same box is the default installation setting for Backup Exec.
But lately we've been having some trouble with Backup Exec. And
wouldn't you know it? Some mismatched MDAC files turned up in the
course of investigation, and now Veritas/Symantec technical support is
insisting upon having the information in the OP before proceeding
further with the case.
So to answer your question: Knowing that this is an MSDE installation,
I was able to Google up this command line...
osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
...but I'm prompted for a password which I do not believe that I
posses.
I've tried running it with the local administrator account and the
domain administrator account. No luck.
Believe me, your continued assistance is appreciated!|||Tim,
If you are using an Windows administrator id I think that use can use the -E
rather than -U parameter. This should not ask for a password.
From the MSDE SP4 readme
1.5 Verify the Version of Microsoft Data Access Components
MSDE 2000 SP4 setup determines whether to upgrade an installed version of
Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
obtain MDAC 2.8 SP2.
c.. MDAC 2.8 SP1 is not installed on computers that already have installed
an equal or later version of MDAC.
d..
e.. 1.6 Identify the Current Version of MSDE 2000
Before running Setup, identify the version of the MSDE 2000 instance that
is being upgraded. If the version of MSDE 2000 is already at or greater than
SP4, you do not need to install SP4.
To identify the installed version of MSDE 2000:
1.. Execute one of the following queries against an instance of the
database engine by using isql, osql, or Query Analyzer.
a.. SELECT SERVERPROPERTY('ProductLevel')
b.. SELECT @.@.VERSION
c.. SELECT SERVERPROPERTY('ProductVersion')
2.. Find out your version of MSDE by means of the following table. SQL
Server 2000 Version and Level @.@.VERSION Product Level
SQL Server 2000 Original Release 8.00.194 RTM
Desktop Engine SP1 8.00.384 SP1
Desktop Engine SP2 8.00.534 SP2
Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
MSDE 2000 SP4 8.00.2039 SP4
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>|||Tim,
Did you find out the build of MSDE?
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>|||Chris,
This thread speaks to a problem I created on our SBS 2003 with MDAC now
having 5 mismatched file versions and a crippled Veritas BackupExec 10, not
to mention the other problems this MDAC issue is causing. I lost RAS
yesterday (related? who knows!) and I can no longer access our Exchange
Server through the Web access for Outlook 2003.
I really messed things up and need help to get the correct MDAC files
restored. I used the cc.exe. Component Checker from MS to test the installed
version against the expected file versions.
Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
HELP!
Chris
"Chris Wood" wrote:
> Tim,
> If you are using an Windows administrator id I think that use can use the
-E
> rather than -U parameter. This should not ask for a password.
> From the MSDE SP4 readme
> 1.5 Verify the Version of Microsoft Data Access Components
> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
>
> b.. Computers that run Windows XP or Windows Server 2003 are not upgrade
d
> to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1
to
> obtain MDAC 2.8 SP2.
>
> c.. MDAC 2.8 SP1 is not installed on computers that already have install
ed
> an equal or later version of MDAC.
> d..
> e.. 1.6 Identify the Current Version of MSDE 2000
> Before running Setup, identify the version of the MSDE 2000 instance tha
t
> is being upgraded. If the version of MSDE 2000 is already at or greater th
an
> SP4, you do not need to install SP4.
> To identify the installed version of MSDE 2000:
> 1.. Execute one of the following queries against an instance of the
> database engine by using isql, osql, or Query Analyzer.
> a.. SELECT SERVERPROPERTY('ProductLevel')
>
> b.. SELECT @.@.VERSION
>
> c.. SELECT SERVERPROPERTY('ProductVersion')
> 2.. Find out your version of MSDE by means of the following table. SQL
> Server 2000 Version and Level @.@.VERSION Product Level
> SQL Server 2000 Original Release 8.00.194 RTM
> Desktop Engine SP1 8.00.384 SP1
> Desktop Engine SP2 8.00.534 SP2
> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
> MSDE 2000 SP4 8.00.2039 SP4
> Chris
> <tim@.tcsys.com> wrote in message
> news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
>
>|||Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
the Premium edition that includes full blown SQL2000 SP4.
If this is SP1 then my previous note about MDAC applies.
Chris
"Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...[vbcol=seagreen]
> Chris,
> This thread speaks to a problem I created on our SBS 2003 with MDAC now
> having 5 mismatched file versions and a crippled Veritas BackupExec 10,
> not
> to mention the other problems this MDAC issue is causing. I lost RAS
> yesterday (related? who knows!) and I can no longer access our Exchange
> Server through the Web access for Outlook 2003.
> I really messed things up and need help to get the correct MDAC files
> restored. I used the cc.exe. Component Checker from MS to test the
> installed
> version against the expected file versions.
> Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
> HELP!
> Chris
> "Chris Wood" wrote:
>|||Chris (Wood),
Are you asking about my server issue or the one from Tim? We are not at SP1
for our SBS 2003 yet because the server would not allow Windows Update to
properly run much less update it's components. I have all 5 of the Microsoft
specified downloads for SBS 2003 SP1 downloaded as per an article I read on
the SBS MS site. I was planning to do some more reading on this before tryin
g
to apply them and was hoping that would fix my browser issue that kept it
from running Windows Update properly.
Frankly this server was a walking abortion from the get go with the company
that originally installed it doing a very poor job. I band-aided everything
I
could safely do to even get it to run without daily unexpected re-boots. I
know that was putting off the inevidable, but the company needed to get back
to daily operations after 30+ days of dissruption caused by this "other"
outside computer company. We have since severed ties with them.
Anyway, we are running with only the original installation of SBS 2003, some
security patches in place and not much else. I also wanted to update the
exchange server to SP1 (this is part of the process I hope to complete once
I
fix my MDAC issues).
Since I last posted, I tossed in my towel on this and have a engineer coming
in this morning from a group that has been trying to get our business for
some time now. I hope he will know what to do to fix this MDAC problem.
But any input you can offer will be good. Also, we are running the standard
version of SBS 2003, not the premium, thus the SQL is only that MSDE2000,
which I am growing to hate by the minute. I would have ponyed up the money
for the premium if I where actually working here when they were forced to ge
t
a new server back in December 2004. (The old server was a Netware server tha
t
this same outside computer company supported, broke and then said it's bette
r
to scrap that server and replace it with the SBS 2003 they installed - This
Machine. We all know how well a job they did on that too!)
Sorry to rant. It's been a long week and I am stressed out.
Chris W.
"Chris Wood" wrote:
> Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you ha
ve
> the Premium edition that includes full blown SQL2000 SP4.
> If this is SP1 then my previous note about MDAC applies.
> Chris
> "Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in messa
ge
> news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...
>
>
On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
server? Very confusing. Will someone help me get my head around this?
Further, when I set the Component Checker to perform analysis against a
selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
8.50.2162.0 is expected. Is this also anything to be concerned about?
Thanks,
Tim ==Tim,
You don't mention the level of SQL2000 that you are running? Is it SP4?
Chris Wood
<tim@.tcsys.com> wrote in message
news:1123081469.455549.23850@.f14g2000cwb.googlegroups.com...
> Greetings,
> On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
> reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
> MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
> server? Very confusing. Will someone help me get my head around this?
> Further, when I set the Component Checker to perform analysis against a
> selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
> inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
> 8.50.2162.0 is expected. Is this also anything to be concerned about?
> Thanks,
> Tim ==
>|||Thanks for replying, Chris.
I know almost nothing about SQL server, but, that being said, I'm an
otherwise competent MS net admin.
This particular box has an MSDE engine installed by an not-profit
financial application. The management of this app is hands-off, under
the control of the vendor.
The thing is, the same server is also our Backup Exec box. Backup Exec
was configured to use the same SQL instance as the financial app.
That's not unusual; the use of an existing SQL or MSDE instance on the
same box is the default installation setting for Backup Exec.
But lately we've been having some trouble with Backup Exec. And
wouldn't you know it? Some mismatched MDAC files turned up in the
course of investigation, and now Veritas/Symantec technical support is
insisting upon having the information in the OP before proceeding
further with the case.
So to answer your question: Knowing that this is an MSDE installation,
I was able to Google up this command line...
osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
...but I'm prompted for a password which I do not believe that I
posses.
I've tried running it with the local administrator account and the
domain administrator account. No luck.
Believe me, your continued assistance is appreciated!|||Tim,
If you are using an Windows administrator id I think that use can use the -E
rather than -U parameter. This should not ask for a password.
From the MSDE SP4 readme
1.5 Verify the Version of Microsoft Data Access Components
MSDE 2000 SP4 setup determines whether to upgrade an installed version of
Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
obtain MDAC 2.8 SP2.
c.. MDAC 2.8 SP1 is not installed on computers that already have installed
an equal or later version of MDAC.
d..
e.. 1.6 Identify the Current Version of MSDE 2000
Before running Setup, identify the version of the MSDE 2000 instance that
is being upgraded. If the version of MSDE 2000 is already at or greater than
SP4, you do not need to install SP4.
To identify the installed version of MSDE 2000:
1.. Execute one of the following queries against an instance of the
database engine by using isql, osql, or Query Analyzer.
a.. SELECT SERVERPROPERTY('ProductLevel')
b.. SELECT @.@.VERSION
c.. SELECT SERVERPROPERTY('ProductVersion')
2.. Find out your version of MSDE by means of the following table. SQL
Server 2000 Version and Level @.@.VERSION Product Level
SQL Server 2000 Original Release 8.00.194 RTM
Desktop Engine SP1 8.00.384 SP1
Desktop Engine SP2 8.00.534 SP2
Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
MSDE 2000 SP4 8.00.2039 SP4
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>|||Tim,
Did you find out the build of MSDE?
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>|||Chris,
This thread speaks to a problem I created on our SBS 2003 with MDAC now
having 5 mismatched file versions and a crippled Veritas BackupExec 10, not
to mention the other problems this MDAC issue is causing. I lost RAS
yesterday (related? who knows!) and I can no longer access our Exchange
Server through the Web access for Outlook 2003.
I really messed things up and need help to get the correct MDAC files
restored. I used the cc.exe. Component Checker from MS to test the installed
version against the expected file versions.
Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
HELP!
Chris
"Chris Wood" wrote:
> Tim,
> If you are using an Windows administrator id I think that use can use the
-E
> rather than -U parameter. This should not ask for a password.
> From the MSDE SP4 readme
> 1.5 Verify the Version of Microsoft Data Access Components
> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
>
> b.. Computers that run Windows XP or Windows Server 2003 are not upgrade
d
> to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1
to
> obtain MDAC 2.8 SP2.
>
> c.. MDAC 2.8 SP1 is not installed on computers that already have install
ed
> an equal or later version of MDAC.
> d..
> e.. 1.6 Identify the Current Version of MSDE 2000
> Before running Setup, identify the version of the MSDE 2000 instance tha
t
> is being upgraded. If the version of MSDE 2000 is already at or greater th
an
> SP4, you do not need to install SP4.
> To identify the installed version of MSDE 2000:
> 1.. Execute one of the following queries against an instance of the
> database engine by using isql, osql, or Query Analyzer.
> a.. SELECT SERVERPROPERTY('ProductLevel')
>
> b.. SELECT @.@.VERSION
>
> c.. SELECT SERVERPROPERTY('ProductVersion')
> 2.. Find out your version of MSDE by means of the following table. SQL
> Server 2000 Version and Level @.@.VERSION Product Level
> SQL Server 2000 Original Release 8.00.194 RTM
> Desktop Engine SP1 8.00.384 SP1
> Desktop Engine SP2 8.00.534 SP2
> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
> MSDE 2000 SP4 8.00.2039 SP4
> Chris
> <tim@.tcsys.com> wrote in message
> news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
>
>|||Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
the Premium edition that includes full blown SQL2000 SP4.
If this is SP1 then my previous note about MDAC applies.
Chris
"Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...[vbcol=seagreen]
> Chris,
> This thread speaks to a problem I created on our SBS 2003 with MDAC now
> having 5 mismatched file versions and a crippled Veritas BackupExec 10,
> not
> to mention the other problems this MDAC issue is causing. I lost RAS
> yesterday (related? who knows!) and I can no longer access our Exchange
> Server through the Web access for Outlook 2003.
> I really messed things up and need help to get the correct MDAC files
> restored. I used the cc.exe. Component Checker from MS to test the
> installed
> version against the expected file versions.
> Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
> HELP!
> Chris
> "Chris Wood" wrote:
>|||Chris (Wood),
Are you asking about my server issue or the one from Tim? We are not at SP1
for our SBS 2003 yet because the server would not allow Windows Update to
properly run much less update it's components. I have all 5 of the Microsoft
specified downloads for SBS 2003 SP1 downloaded as per an article I read on
the SBS MS site. I was planning to do some more reading on this before tryin
g
to apply them and was hoping that would fix my browser issue that kept it
from running Windows Update properly.
Frankly this server was a walking abortion from the get go with the company
that originally installed it doing a very poor job. I band-aided everything
I
could safely do to even get it to run without daily unexpected re-boots. I
know that was putting off the inevidable, but the company needed to get back
to daily operations after 30+ days of dissruption caused by this "other"
outside computer company. We have since severed ties with them.
Anyway, we are running with only the original installation of SBS 2003, some
security patches in place and not much else. I also wanted to update the
exchange server to SP1 (this is part of the process I hope to complete once
I
fix my MDAC issues).
Since I last posted, I tossed in my towel on this and have a engineer coming
in this morning from a group that has been trying to get our business for
some time now. I hope he will know what to do to fix this MDAC problem.
But any input you can offer will be good. Also, we are running the standard
version of SBS 2003, not the premium, thus the SQL is only that MSDE2000,
which I am growing to hate by the minute. I would have ponyed up the money
for the premium if I where actually working here when they were forced to ge
t
a new server back in December 2004. (The old server was a Netware server tha
t
this same outside computer company supported, broke and then said it's bette
r
to scrap that server and replace it with the SBS 2003 they installed - This
Machine. We all know how well a job they did on that too!)
Sorry to rant. It's been a long week and I am stressed out.
Chris W.
"Chris Wood" wrote:
> Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you ha
ve
> the Premium edition that includes full blown SQL2000 SP4.
> If this is SP1 then my previous note about MDAC applies.
> Chris
> "Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in messa
ge
> news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...
>
>
MDAC Madness
Greetings,
On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
server? Very confusing. Will someone help me get my head around this?
Further, when I set the Component Checker to perform analysis against a
selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
8.50.2162.0 is expected. Is this also anything to be concerned about?
Thanks,
Tim ==
Tim,
You don't mention the level of SQL2000 that you are running? Is it SP4?
Chris Wood
<tim@.tcsys.com> wrote in message
news:1123081469.455549.23850@.f14g2000cwb.googlegro ups.com...
> Greetings,
> On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
> reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
> MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
> server? Very confusing. Will someone help me get my head around this?
> Further, when I set the Component Checker to perform analysis against a
> selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
> inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
> 8.50.2162.0 is expected. Is this also anything to be concerned about?
> Thanks,
> Tim ==
>
|||Thanks for replying, Chris.
I know almost nothing about SQL server, but, that being said, I'm an
otherwise competent MS net admin.
This particular box has an MSDE engine installed by an not-profit
financial application. The management of this app is hands-off, under
the control of the vendor.
The thing is, the same server is also our Backup Exec box. Backup Exec
was configured to use the same SQL instance as the financial app.
That's not unusual; the use of an existing SQL or MSDE instance on the
same box is the default installation setting for Backup Exec.
But lately we've been having some trouble with Backup Exec. And
wouldn't you know it? Some mismatched MDAC files turned up in the
course of investigation, and now Veritas/Symantec technical support is
insisting upon having the information in the OP before proceeding
further with the case.
So to answer your question: Knowing that this is an MSDE installation,
I was able to Google up this command line...
osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
...but I'm prompted for a password which I do not believe that I
posses.
I've tried running it with the local administrator account and the
domain administrator account. No luck.
Believe me, your continued assistance is appreciated!
|||Tim,
If you are using an Windows administrator id I think that use can use the -E
rather than -U parameter. This should not ask for a password.
From the MSDE SP4 readme
1.5 Verify the Version of Microsoft Data Access Components
MSDE 2000 SP4 setup determines whether to upgrade an installed version of
Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
obtain MDAC 2.8 SP2.
c.. MDAC 2.8 SP1 is not installed on computers that already have installed
an equal or later version of MDAC.
d..
e.. 1.6 Identify the Current Version of MSDE 2000
Before running Setup, identify the version of the MSDE 2000 instance that
is being upgraded. If the version of MSDE 2000 is already at or greater than
SP4, you do not need to install SP4.
To identify the installed version of MSDE 2000:
1.. Execute one of the following queries against an instance of the
database engine by using isql, osql, or Query Analyzer.
a.. SELECT SERVERPROPERTY('ProductLevel')
b.. SELECT @.@.VERSION
c.. SELECT SERVERPROPERTY('ProductVersion')
2.. Find out your version of MSDE by means of the following table. SQL
Server 2000 Version and Level @.@.VERSION Product Level
SQL Server 2000 Original Release 8.00.194 RTM
Desktop Engine SP1 8.00.384 SP1
Desktop Engine SP2 8.00.534 SP2
Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
MSDE 2000 SP4 8.00.2039 SP4
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegr oups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>
|||Tim,
Did you find out the build of MSDE?
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegr oups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>
|||Chris,
This thread speaks to a problem I created on our SBS 2003 with MDAC now
having 5 mismatched file versions and a crippled Veritas BackupExec 10, not
to mention the other problems this MDAC issue is causing. I lost RAS
yesterday (related? who knows!) and I can no longer access our Exchange
Server through the Web access for Outlook 2003.
I really messed things up and need help to get the correct MDAC files
restored. I used the cc.exe. Component Checker from MS to test the installed
version against the expected file versions.
Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
HELP!
Chris
"Chris Wood" wrote:
> Tim,
> If you are using an Windows administrator id I think that use can use the -E
> rather than -U parameter. This should not ask for a password.
> From the MSDE SP4 readme
> 1.5 Verify the Version of Microsoft Data Access Components
> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
>
> b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
> to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
> obtain MDAC 2.8 SP2.
>
> c.. MDAC 2.8 SP1 is not installed on computers that already have installed
> an equal or later version of MDAC.
> d..
> e.. 1.6 Identify the Current Version of MSDE 2000
> Before running Setup, identify the version of the MSDE 2000 instance that
> is being upgraded. If the version of MSDE 2000 is already at or greater than
> SP4, you do not need to install SP4.
> To identify the installed version of MSDE 2000:
> 1.. Execute one of the following queries against an instance of the
> database engine by using isql, osql, or Query Analyzer.
> a.. SELECT SERVERPROPERTY('ProductLevel')
>
> b.. SELECT @.@.VERSION
>
> c.. SELECT SERVERPROPERTY('ProductVersion')
> 2.. Find out your version of MSDE by means of the following table. SQL
> Server 2000 Version and Level @.@.VERSION Product Level
> SQL Server 2000 Original Release 8.00.194 RTM
> Desktop Engine SP1 8.00.384 SP1
> Desktop Engine SP2 8.00.534 SP2
> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
> MSDE 2000 SP4 8.00.2039 SP4
> Chris
> <tim@.tcsys.com> wrote in message
> news:1123100308.823774.310400@.g49g2000cwa.googlegr oups.com...
>
>
|||Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
the Premium edition that includes full blown SQL2000 SP4.
If this is SP1 then my previous note about MDAC applies.
Chris
"Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...[vbcol=seagreen]
> Chris,
> This thread speaks to a problem I created on our SBS 2003 with MDAC now
> having 5 mismatched file versions and a crippled Veritas BackupExec 10,
> not
> to mention the other problems this MDAC issue is causing. I lost RAS
> yesterday (related? who knows!) and I can no longer access our Exchange
> Server through the Web access for Outlook 2003.
> I really messed things up and need help to get the correct MDAC files
> restored. I used the cc.exe. Component Checker from MS to test the
> installed
> version against the expected file versions.
> Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
> HELP!
> Chris
> "Chris Wood" wrote:
|||Chris (Wood),
Are you asking about my server issue or the one from Tim? We are not at SP1
for our SBS 2003 yet because the server would not allow Windows Update to
properly run much less update it's components. I have all 5 of the Microsoft
specified downloads for SBS 2003 SP1 downloaded as per an article I read on
the SBS MS site. I was planning to do some more reading on this before trying
to apply them and was hoping that would fix my browser issue that kept it
from running Windows Update properly.
Frankly this server was a walking abortion from the get go with the company
that originally installed it doing a very poor job. I band-aided everything I
could safely do to even get it to run without daily unexpected re-boots. I
know that was putting off the inevidable, but the company needed to get back
to daily operations after 30+ days of dissruption caused by this "other"
outside computer company. We have since severed ties with them.
Anyway, we are running with only the original installation of SBS 2003, some
security patches in place and not much else. I also wanted to update the
exchange server to SP1 (this is part of the process I hope to complete once I
fix my MDAC issues).
Since I last posted, I tossed in my towel on this and have a engineer coming
in this morning from a group that has been trying to get our business for
some time now. I hope he will know what to do to fix this MDAC problem.
But any input you can offer will be good. Also, we are running the standard
version of SBS 2003, not the premium, thus the SQL is only that MSDE2000,
which I am growing to hate by the minute. I would have ponyed up the money
for the premium if I where actually working here when they were forced to get
a new server back in December 2004. (The old server was a Netware server that
this same outside computer company supported, broke and then said it's better
to scrap that server and replace it with the SBS 2003 they installed - This
Machine. We all know how well a job they did on that too!)
Sorry to rant. It's been a long week and I am stressed out.
Chris W.
"Chris Wood" wrote:
> Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
> the Premium edition that includes full blown SQL2000 SP4.
> If this is SP1 then my previous note about MDAC applies.
> Chris
> "Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
> news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...
>
>
On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
server? Very confusing. Will someone help me get my head around this?
Further, when I set the Component Checker to perform analysis against a
selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
8.50.2162.0 is expected. Is this also anything to be concerned about?
Thanks,
Tim ==
Tim,
You don't mention the level of SQL2000 that you are running? Is it SP4?
Chris Wood
<tim@.tcsys.com> wrote in message
news:1123081469.455549.23850@.f14g2000cwb.googlegro ups.com...
> Greetings,
> On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
> reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
> MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
> server? Very confusing. Will someone help me get my head around this?
> Further, when I set the Component Checker to perform analysis against a
> selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
> inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
> 8.50.2162.0 is expected. Is this also anything to be concerned about?
> Thanks,
> Tim ==
>
|||Thanks for replying, Chris.
I know almost nothing about SQL server, but, that being said, I'm an
otherwise competent MS net admin.
This particular box has an MSDE engine installed by an not-profit
financial application. The management of this app is hands-off, under
the control of the vendor.
The thing is, the same server is also our Backup Exec box. Backup Exec
was configured to use the same SQL instance as the financial app.
That's not unusual; the use of an existing SQL or MSDE instance on the
same box is the default installation setting for Backup Exec.
But lately we've been having some trouble with Backup Exec. And
wouldn't you know it? Some mismatched MDAC files turned up in the
course of investigation, and now Veritas/Symantec technical support is
insisting upon having the information in the OP before proceeding
further with the case.
So to answer your question: Knowing that this is an MSDE installation,
I was able to Google up this command line...
osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
...but I'm prompted for a password which I do not believe that I
posses.
I've tried running it with the local administrator account and the
domain administrator account. No luck.
Believe me, your continued assistance is appreciated!
|||Tim,
If you are using an Windows administrator id I think that use can use the -E
rather than -U parameter. This should not ask for a password.
From the MSDE SP4 readme
1.5 Verify the Version of Microsoft Data Access Components
MSDE 2000 SP4 setup determines whether to upgrade an installed version of
Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
obtain MDAC 2.8 SP2.
c.. MDAC 2.8 SP1 is not installed on computers that already have installed
an equal or later version of MDAC.
d..
e.. 1.6 Identify the Current Version of MSDE 2000
Before running Setup, identify the version of the MSDE 2000 instance that
is being upgraded. If the version of MSDE 2000 is already at or greater than
SP4, you do not need to install SP4.
To identify the installed version of MSDE 2000:
1.. Execute one of the following queries against an instance of the
database engine by using isql, osql, or Query Analyzer.
a.. SELECT SERVERPROPERTY('ProductLevel')
b.. SELECT @.@.VERSION
c.. SELECT SERVERPROPERTY('ProductVersion')
2.. Find out your version of MSDE by means of the following table. SQL
Server 2000 Version and Level @.@.VERSION Product Level
SQL Server 2000 Original Release 8.00.194 RTM
Desktop Engine SP1 8.00.384 SP1
Desktop Engine SP2 8.00.534 SP2
Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
MSDE 2000 SP4 8.00.2039 SP4
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegr oups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>
|||Tim,
Did you find out the build of MSDE?
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegr oups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>
|||Chris,
This thread speaks to a problem I created on our SBS 2003 with MDAC now
having 5 mismatched file versions and a crippled Veritas BackupExec 10, not
to mention the other problems this MDAC issue is causing. I lost RAS
yesterday (related? who knows!) and I can no longer access our Exchange
Server through the Web access for Outlook 2003.
I really messed things up and need help to get the correct MDAC files
restored. I used the cc.exe. Component Checker from MS to test the installed
version against the expected file versions.
Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
HELP!
Chris
"Chris Wood" wrote:
> Tim,
> If you are using an Windows administrator id I think that use can use the -E
> rather than -U parameter. This should not ask for a password.
> From the MSDE SP4 readme
> 1.5 Verify the Version of Microsoft Data Access Components
> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
>
> b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
> to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
> obtain MDAC 2.8 SP2.
>
> c.. MDAC 2.8 SP1 is not installed on computers that already have installed
> an equal or later version of MDAC.
> d..
> e.. 1.6 Identify the Current Version of MSDE 2000
> Before running Setup, identify the version of the MSDE 2000 instance that
> is being upgraded. If the version of MSDE 2000 is already at or greater than
> SP4, you do not need to install SP4.
> To identify the installed version of MSDE 2000:
> 1.. Execute one of the following queries against an instance of the
> database engine by using isql, osql, or Query Analyzer.
> a.. SELECT SERVERPROPERTY('ProductLevel')
>
> b.. SELECT @.@.VERSION
>
> c.. SELECT SERVERPROPERTY('ProductVersion')
> 2.. Find out your version of MSDE by means of the following table. SQL
> Server 2000 Version and Level @.@.VERSION Product Level
> SQL Server 2000 Original Release 8.00.194 RTM
> Desktop Engine SP1 8.00.384 SP1
> Desktop Engine SP2 8.00.534 SP2
> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
> MSDE 2000 SP4 8.00.2039 SP4
> Chris
> <tim@.tcsys.com> wrote in message
> news:1123100308.823774.310400@.g49g2000cwa.googlegr oups.com...
>
>
|||Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
the Premium edition that includes full blown SQL2000 SP4.
If this is SP1 then my previous note about MDAC applies.
Chris
"Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...[vbcol=seagreen]
> Chris,
> This thread speaks to a problem I created on our SBS 2003 with MDAC now
> having 5 mismatched file versions and a crippled Veritas BackupExec 10,
> not
> to mention the other problems this MDAC issue is causing. I lost RAS
> yesterday (related? who knows!) and I can no longer access our Exchange
> Server through the Web access for Outlook 2003.
> I really messed things up and need help to get the correct MDAC files
> restored. I used the cc.exe. Component Checker from MS to test the
> installed
> version against the expected file versions.
> Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
> HELP!
> Chris
> "Chris Wood" wrote:
|||Chris (Wood),
Are you asking about my server issue or the one from Tim? We are not at SP1
for our SBS 2003 yet because the server would not allow Windows Update to
properly run much less update it's components. I have all 5 of the Microsoft
specified downloads for SBS 2003 SP1 downloaded as per an article I read on
the SBS MS site. I was planning to do some more reading on this before trying
to apply them and was hoping that would fix my browser issue that kept it
from running Windows Update properly.
Frankly this server was a walking abortion from the get go with the company
that originally installed it doing a very poor job. I band-aided everything I
could safely do to even get it to run without daily unexpected re-boots. I
know that was putting off the inevidable, but the company needed to get back
to daily operations after 30+ days of dissruption caused by this "other"
outside computer company. We have since severed ties with them.
Anyway, we are running with only the original installation of SBS 2003, some
security patches in place and not much else. I also wanted to update the
exchange server to SP1 (this is part of the process I hope to complete once I
fix my MDAC issues).
Since I last posted, I tossed in my towel on this and have a engineer coming
in this morning from a group that has been trying to get our business for
some time now. I hope he will know what to do to fix this MDAC problem.
But any input you can offer will be good. Also, we are running the standard
version of SBS 2003, not the premium, thus the SQL is only that MSDE2000,
which I am growing to hate by the minute. I would have ponyed up the money
for the premium if I where actually working here when they were forced to get
a new server back in December 2004. (The old server was a Netware server that
this same outside computer company supported, broke and then said it's better
to scrap that server and replace it with the SBS 2003 they installed - This
Machine. We all know how well a job they did on that too!)
Sorry to rant. It's been a long week and I am stressed out.
Chris W.
"Chris Wood" wrote:
> Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
> the Premium edition that includes full blown SQL2000 SP4.
> If this is SP1 then my previous note about MDAC applies.
> Chris
> "Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
> news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...
>
>
Wednesday, March 28, 2012
MDAC Madness
Greetings,
On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
server? Very confusing. Will someone help me get my head around this?
Further, when I set the Component Checker to perform analysis against a
selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
8.50.2162.0 is expected. Is this also anything to be concerned about?
Thanks,
Tim ==Tim,
You don't mention the level of SQL2000 that you are running? Is it SP4?
Chris Wood
<tim@.tcsys.com> wrote in message
news:1123081469.455549.23850@.f14g2000cwb.googlegroups.com...
> Greetings,
> On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
> reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
> MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
> server? Very confusing. Will someone help me get my head around this?
> Further, when I set the Component Checker to perform analysis against a
> selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
> inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
> 8.50.2162.0 is expected. Is this also anything to be concerned about?
> Thanks,
> Tim ==>|||Thanks for replying, Chris.
I know almost nothing about SQL server, but, that being said, I'm an
otherwise competent MS net admin.
This particular box has an MSDE engine installed by an not-profit
financial application. The management of this app is hands-off, under
the control of the vendor.
The thing is, the same server is also our Backup Exec box. Backup Exec
was configured to use the same SQL instance as the financial app.
That's not unusual; the use of an existing SQL or MSDE instance on the
same box is the default installation setting for Backup Exec.
But lately we've been having some trouble with Backup Exec. And
wouldn't you know it? Some mismatched MDAC files turned up in the
course of investigation, and now Veritas/Symantec technical support is
insisting upon having the information in the OP before proceeding
further with the case.
So to answer your question: Knowing that this is an MSDE installation,
I was able to Google up this command line...
osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
...but I'm prompted for a password which I do not believe that I
posses.
I've tried running it with the local administrator account and the
domain administrator account. No luck.
Believe me, your continued assistance is appreciated!|||Tim,
If you are using an Windows administrator id I think that use can use the -E
rather than -U parameter. This should not ask for a password.
From the MSDE SP4 readme
1.5 Verify the Version of Microsoft Data Access Components
MSDE 2000 SP4 setup determines whether to upgrade an installed version of
Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
obtain MDAC 2.8 SP2.
c.. MDAC 2.8 SP1 is not installed on computers that already have installed
an equal or later version of MDAC.
d..
e.. 1.6 Identify the Current Version of MSDE 2000
Before running Setup, identify the version of the MSDE 2000 instance that
is being upgraded. If the version of MSDE 2000 is already at or greater than
SP4, you do not need to install SP4.
To identify the installed version of MSDE 2000:
1.. Execute one of the following queries against an instance of the
database engine by using isql, osql, or Query Analyzer.
a.. SELECT SERVERPROPERTY('ProductLevel')
b.. SELECT @.@.VERSION
c.. SELECT SERVERPROPERTY('ProductVersion')
2.. Find out your version of MSDE by means of the following table. SQL
Server 2000 Version and Level @.@.VERSION Product Level
SQL Server 2000 Original Release 8.00.194 RTM
Desktop Engine SP1 8.00.384 SP1
Desktop Engine SP2 8.00.534 SP2
Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
MSDE 2000 SP4 8.00.2039 SP4
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>|||Tim,
Did you find out the build of MSDE?
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>|||Chris,
This thread speaks to a problem I created on our SBS 2003 with MDAC now
having 5 mismatched file versions and a crippled Veritas BackupExec 10, not
to mention the other problems this MDAC issue is causing. I lost RAS
yesterday (related? who knows!) and I can no longer access our Exchange
Server through the Web access for Outlook 2003.
I really messed things up and need help to get the correct MDAC files
restored. I used the cc.exe. Component Checker from MS to test the installed
version against the expected file versions.
Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
HELP!
Chris
"Chris Wood" wrote:
> Tim,
> If you are using an Windows administrator id I think that use can use the -E
> rather than -U parameter. This should not ask for a password.
> From the MSDE SP4 readme
> 1.5 Verify the Version of Microsoft Data Access Components
> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
>
> b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
> to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
> obtain MDAC 2.8 SP2.
>
> c.. MDAC 2.8 SP1 is not installed on computers that already have installed
> an equal or later version of MDAC.
> d..
> e.. 1.6 Identify the Current Version of MSDE 2000
> Before running Setup, identify the version of the MSDE 2000 instance that
> is being upgraded. If the version of MSDE 2000 is already at or greater than
> SP4, you do not need to install SP4.
> To identify the installed version of MSDE 2000:
> 1.. Execute one of the following queries against an instance of the
> database engine by using isql, osql, or Query Analyzer.
> a.. SELECT SERVERPROPERTY('ProductLevel')
>
> b.. SELECT @.@.VERSION
>
> c.. SELECT SERVERPROPERTY('ProductVersion')
> 2.. Find out your version of MSDE by means of the following table. SQL
> Server 2000 Version and Level @.@.VERSION Product Level
> SQL Server 2000 Original Release 8.00.194 RTM
> Desktop Engine SP1 8.00.384 SP1
> Desktop Engine SP2 8.00.534 SP2
> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
> MSDE 2000 SP4 8.00.2039 SP4
> Chris
> <tim@.tcsys.com> wrote in message
> news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> > Thanks for replying, Chris.
> >
> > I know almost nothing about SQL server, but, that being said, I'm an
> > otherwise competent MS net admin.
> >
> > This particular box has an MSDE engine installed by an not-profit
> > financial application. The management of this app is hands-off, under
> > the control of the vendor.
> >
> > The thing is, the same server is also our Backup Exec box. Backup Exec
> > was configured to use the same SQL instance as the financial app.
> > That's not unusual; the use of an existing SQL or MSDE instance on the
> > same box is the default installation setting for Backup Exec.
> >
> > But lately we've been having some trouble with Backup Exec. And
> > wouldn't you know it? Some mismatched MDAC files turned up in the
> > course of investigation, and now Veritas/Symantec technical support is
> > insisting upon having the information in the OP before proceeding
> > further with the case.
> >
> > So to answer your question: Knowing that this is an MSDE installation,
> > I was able to Google up this command line...
> > osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> > ...but I'm prompted for a password which I do not believe that I
> > posses.
> >
> > I've tried running it with the local administrator account and the
> > domain administrator account. No luck.
> >
> > Believe me, your continued assistance is appreciated!
> >
>
>|||Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
the Premium edition that includes full blown SQL2000 SP4.
If this is SP1 then my previous note about MDAC applies.
Chris
"Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...
> Chris,
> This thread speaks to a problem I created on our SBS 2003 with MDAC now
> having 5 mismatched file versions and a crippled Veritas BackupExec 10,
> not
> to mention the other problems this MDAC issue is causing. I lost RAS
> yesterday (related? who knows!) and I can no longer access our Exchange
> Server through the Web access for Outlook 2003.
> I really messed things up and need help to get the correct MDAC files
> restored. I used the cc.exe. Component Checker from MS to test the
> installed
> version against the expected file versions.
> Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
> HELP!
> Chris
> "Chris Wood" wrote:
>> Tim,
>> If you are using an Windows administrator id I think that use can use
>> the -E
>> rather than -U parameter. This should not ask for a password.
>> From the MSDE SP4 readme
>> 1.5 Verify the Version of Microsoft Data Access Components
>> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
>> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
>> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
>>
>> b.. Computers that run Windows XP or Windows Server 2003 are not
>> upgraded
>> to MDAC 2.8 SP1. If your system requires any of the fixes included in
>> MDAC
>> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1
>> to
>> obtain MDAC 2.8 SP2.
>>
>> c.. MDAC 2.8 SP1 is not installed on computers that already have
>> installed
>> an equal or later version of MDAC.
>> d..
>> e.. 1.6 Identify the Current Version of MSDE 2000
>> Before running Setup, identify the version of the MSDE 2000 instance
>> that
>> is being upgraded. If the version of MSDE 2000 is already at or greater
>> than
>> SP4, you do not need to install SP4.
>> To identify the installed version of MSDE 2000:
>> 1.. Execute one of the following queries against an instance of the
>> database engine by using isql, osql, or Query Analyzer.
>> a.. SELECT SERVERPROPERTY('ProductLevel')
>>
>> b.. SELECT @.@.VERSION
>>
>> c.. SELECT SERVERPROPERTY('ProductVersion')
>> 2.. Find out your version of MSDE by means of the following table.
>> SQL
>> Server 2000 Version and Level @.@.VERSION Product Level
>> SQL Server 2000 Original Release 8.00.194 RTM
>> Desktop Engine SP1 8.00.384 SP1
>> Desktop Engine SP2 8.00.534 SP2
>> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
>> MSDE 2000 SP4 8.00.2039 SP4
>> Chris
>> <tim@.tcsys.com> wrote in message
>> news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
>> > Thanks for replying, Chris.
>> >
>> > I know almost nothing about SQL server, but, that being said, I'm an
>> > otherwise competent MS net admin.
>> >
>> > This particular box has an MSDE engine installed by an not-profit
>> > financial application. The management of this app is hands-off, under
>> > the control of the vendor.
>> >
>> > The thing is, the same server is also our Backup Exec box. Backup Exec
>> > was configured to use the same SQL instance as the financial app.
>> > That's not unusual; the use of an existing SQL or MSDE instance on the
>> > same box is the default installation setting for Backup Exec.
>> >
>> > But lately we've been having some trouble with Backup Exec. And
>> > wouldn't you know it? Some mismatched MDAC files turned up in the
>> > course of investigation, and now Veritas/Symantec technical support is
>> > insisting upon having the information in the OP before proceeding
>> > further with the case.
>> >
>> > So to answer your question: Knowing that this is an MSDE installation,
>> > I was able to Google up this command line...
>> > osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
>> > ...but I'm prompted for a password which I do not believe that I
>> > posses.
>> >
>> > I've tried running it with the local administrator account and the
>> > domain administrator account. No luck.
>> >
>> > Believe me, your continued assistance is appreciated!
>> >
>>|||Chris (Wood),
Are you asking about my server issue or the one from Tim? We are not at SP1
for our SBS 2003 yet because the server would not allow Windows Update to
properly run much less update it's components. I have all 5 of the Microsoft
specified downloads for SBS 2003 SP1 downloaded as per an article I read on
the SBS MS site. I was planning to do some more reading on this before trying
to apply them and was hoping that would fix my browser issue that kept it
from running Windows Update properly.
Frankly this server was a walking abortion from the get go with the company
that originally installed it doing a very poor job. I band-aided everything I
could safely do to even get it to run without daily unexpected re-boots. I
know that was putting off the inevidable, but the company needed to get back
to daily operations after 30+ days of dissruption caused by this "other"
outside computer company. We have since severed ties with them.
Anyway, we are running with only the original installation of SBS 2003, some
security patches in place and not much else. I also wanted to update the
exchange server to SP1 (this is part of the process I hope to complete once I
fix my MDAC issues).
Since I last posted, I tossed in my towel on this and have a engineer coming
in this morning from a group that has been trying to get our business for
some time now. I hope he will know what to do to fix this MDAC problem.
But any input you can offer will be good. Also, we are running the standard
version of SBS 2003, not the premium, thus the SQL is only that MSDE2000,
which I am growing to hate by the minute. I would have ponyed up the money
for the premium if I where actually working here when they were forced to get
a new server back in December 2004. (The old server was a Netware server that
this same outside computer company supported, broke and then said it's better
to scrap that server and replace it with the SBS 2003 they installed - This
Machine. We all know how well a job they did on that too!)
Sorry to rant. It's been a long week and I am stressed out.
Chris W.
"Chris Wood" wrote:
> Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
> the Premium edition that includes full blown SQL2000 SP4.
> If this is SP1 then my previous note about MDAC applies.
> Chris
> "Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
> news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...
> > Chris,
> >
> > This thread speaks to a problem I created on our SBS 2003 with MDAC now
> > having 5 mismatched file versions and a crippled Veritas BackupExec 10,
> > not
> > to mention the other problems this MDAC issue is causing. I lost RAS
> > yesterday (related? who knows!) and I can no longer access our Exchange
> > Server through the Web access for Outlook 2003.
> >
> > I really messed things up and need help to get the correct MDAC files
> > restored. I used the cc.exe. Component Checker from MS to test the
> > installed
> > version against the expected file versions.
> >
> > Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
> >
> > HELP!
> >
> > Chris
> >
> > "Chris Wood" wrote:
> >
> >> Tim,
> >>
> >> If you are using an Windows administrator id I think that use can use
> >> the -E
> >> rather than -U parameter. This should not ask for a password.
> >>
> >> From the MSDE SP4 readme
> >>
> >> 1.5 Verify the Version of Microsoft Data Access Components
> >> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
> >> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
> >>
> >> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
> >>
> >>
> >> b.. Computers that run Windows XP or Windows Server 2003 are not
> >> upgraded
> >> to MDAC 2.8 SP1. If your system requires any of the fixes included in
> >> MDAC
> >> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1
> >> to
> >> obtain MDAC 2.8 SP2.
> >>
> >>
> >> c.. MDAC 2.8 SP1 is not installed on computers that already have
> >> installed
> >> an equal or later version of MDAC.
> >> d..
> >> e.. 1.6 Identify the Current Version of MSDE 2000
> >> Before running Setup, identify the version of the MSDE 2000 instance
> >> that
> >> is being upgraded. If the version of MSDE 2000 is already at or greater
> >> than
> >> SP4, you do not need to install SP4.
> >>
> >> To identify the installed version of MSDE 2000:
> >>
> >> 1.. Execute one of the following queries against an instance of the
> >> database engine by using isql, osql, or Query Analyzer.
> >> a.. SELECT SERVERPROPERTY('ProductLevel')
> >>
> >>
> >> b.. SELECT @.@.VERSION
> >>
> >>
> >> c.. SELECT SERVERPROPERTY('ProductVersion')
> >> 2.. Find out your version of MSDE by means of the following table.
> >> SQL
> >> Server 2000 Version and Level @.@.VERSION Product Level
> >> SQL Server 2000 Original Release 8.00.194 RTM
> >> Desktop Engine SP1 8.00.384 SP1
> >> Desktop Engine SP2 8.00.534 SP2
> >> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
> >> MSDE 2000 SP4 8.00.2039 SP4
> >>
> >> Chris
> >> <tim@.tcsys.com> wrote in message
> >> news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> >> > Thanks for replying, Chris.
> >> >
> >> > I know almost nothing about SQL server, but, that being said, I'm an
> >> > otherwise competent MS net admin.
> >> >
> >> > This particular box has an MSDE engine installed by an not-profit
> >> > financial application. The management of this app is hands-off, under
> >> > the control of the vendor.
> >> >
> >> > The thing is, the same server is also our Backup Exec box. Backup Exec
> >> > was configured to use the same SQL instance as the financial app.
> >> > That's not unusual; the use of an existing SQL or MSDE instance on the
> >> > same box is the default installation setting for Backup Exec.
> >> >
> >> > But lately we've been having some trouble with Backup Exec. And
> >> > wouldn't you know it? Some mismatched MDAC files turned up in the
> >> > course of investigation, and now Veritas/Symantec technical support is
> >> > insisting upon having the information in the OP before proceeding
> >> > further with the case.
> >> >
> >> > So to answer your question: Knowing that this is an MSDE installation,
> >> > I was able to Google up this command line...
> >> > osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> >> > ...but I'm prompted for a password which I do not believe that I
> >> > posses.
> >> >
> >> > I've tried running it with the local administrator account and the
> >> > domain administrator account. No luck.
> >> >
> >> > Believe me, your continued assistance is appreciated!
> >> >
> >>
> >>
> >>
>
>sql
On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
server? Very confusing. Will someone help me get my head around this?
Further, when I set the Component Checker to perform analysis against a
selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
8.50.2162.0 is expected. Is this also anything to be concerned about?
Thanks,
Tim ==Tim,
You don't mention the level of SQL2000 that you are running? Is it SP4?
Chris Wood
<tim@.tcsys.com> wrote in message
news:1123081469.455549.23850@.f14g2000cwb.googlegroups.com...
> Greetings,
> On my Windows 2000 SP4 Server, the MDAC Component Checker Version 2.0
> reports that MDAC 2.8 SP1 on Windows XP SP2 is installed.
> MDAC 2.8 SP1 on Windows XP SP2 ... but this is a Windows 2000 SP4
> server? Very confusing. Will someone help me get my head around this?
> Further, when I set the Component Checker to perform analysis against a
> selected version, and target MDAC 2.8 SP1 on Windows XP SP2, only one
> inconsistency is reported -- msxml3.dll is at version 8.70.1104.0, but
> 8.50.2162.0 is expected. Is this also anything to be concerned about?
> Thanks,
> Tim ==>|||Thanks for replying, Chris.
I know almost nothing about SQL server, but, that being said, I'm an
otherwise competent MS net admin.
This particular box has an MSDE engine installed by an not-profit
financial application. The management of this app is hands-off, under
the control of the vendor.
The thing is, the same server is also our Backup Exec box. Backup Exec
was configured to use the same SQL instance as the financial app.
That's not unusual; the use of an existing SQL or MSDE instance on the
same box is the default installation setting for Backup Exec.
But lately we've been having some trouble with Backup Exec. And
wouldn't you know it? Some mismatched MDAC files turned up in the
course of investigation, and now Veritas/Symantec technical support is
insisting upon having the information in the OP before proceeding
further with the case.
So to answer your question: Knowing that this is an MSDE installation,
I was able to Google up this command line...
osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
...but I'm prompted for a password which I do not believe that I
posses.
I've tried running it with the local administrator account and the
domain administrator account. No luck.
Believe me, your continued assistance is appreciated!|||Tim,
If you are using an Windows administrator id I think that use can use the -E
rather than -U parameter. This should not ask for a password.
From the MSDE SP4 readme
1.5 Verify the Version of Microsoft Data Access Components
MSDE 2000 SP4 setup determines whether to upgrade an installed version of
Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
obtain MDAC 2.8 SP2.
c.. MDAC 2.8 SP1 is not installed on computers that already have installed
an equal or later version of MDAC.
d..
e.. 1.6 Identify the Current Version of MSDE 2000
Before running Setup, identify the version of the MSDE 2000 instance that
is being upgraded. If the version of MSDE 2000 is already at or greater than
SP4, you do not need to install SP4.
To identify the installed version of MSDE 2000:
1.. Execute one of the following queries against an instance of the
database engine by using isql, osql, or Query Analyzer.
a.. SELECT SERVERPROPERTY('ProductLevel')
b.. SELECT @.@.VERSION
c.. SELECT SERVERPROPERTY('ProductVersion')
2.. Find out your version of MSDE by means of the following table. SQL
Server 2000 Version and Level @.@.VERSION Product Level
SQL Server 2000 Original Release 8.00.194 RTM
Desktop Engine SP1 8.00.384 SP1
Desktop Engine SP2 8.00.534 SP2
Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
MSDE 2000 SP4 8.00.2039 SP4
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>|||Tim,
Did you find out the build of MSDE?
Chris
<tim@.tcsys.com> wrote in message
news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> Thanks for replying, Chris.
> I know almost nothing about SQL server, but, that being said, I'm an
> otherwise competent MS net admin.
> This particular box has an MSDE engine installed by an not-profit
> financial application. The management of this app is hands-off, under
> the control of the vendor.
> The thing is, the same server is also our Backup Exec box. Backup Exec
> was configured to use the same SQL instance as the financial app.
> That's not unusual; the use of an existing SQL or MSDE instance on the
> same box is the default installation setting for Backup Exec.
> But lately we've been having some trouble with Backup Exec. And
> wouldn't you know it? Some mismatched MDAC files turned up in the
> course of investigation, and now Veritas/Symantec technical support is
> insisting upon having the information in the OP before proceeding
> further with the case.
> So to answer your question: Knowing that this is an MSDE installation,
> I was able to Google up this command line...
> osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> ...but I'm prompted for a password which I do not believe that I
> posses.
> I've tried running it with the local administrator account and the
> domain administrator account. No luck.
> Believe me, your continued assistance is appreciated!
>|||Chris,
This thread speaks to a problem I created on our SBS 2003 with MDAC now
having 5 mismatched file versions and a crippled Veritas BackupExec 10, not
to mention the other problems this MDAC issue is causing. I lost RAS
yesterday (related? who knows!) and I can no longer access our Exchange
Server through the Web access for Outlook 2003.
I really messed things up and need help to get the correct MDAC files
restored. I used the cc.exe. Component Checker from MS to test the installed
version against the expected file versions.
Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
HELP!
Chris
"Chris Wood" wrote:
> Tim,
> If you are using an Windows administrator id I think that use can use the -E
> rather than -U parameter. This should not ask for a password.
> From the MSDE SP4 readme
> 1.5 Verify the Version of Microsoft Data Access Components
> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
>
> b.. Computers that run Windows XP or Windows Server 2003 are not upgraded
> to MDAC 2.8 SP1. If your system requires any of the fixes included in MDAC
> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1 to
> obtain MDAC 2.8 SP2.
>
> c.. MDAC 2.8 SP1 is not installed on computers that already have installed
> an equal or later version of MDAC.
> d..
> e.. 1.6 Identify the Current Version of MSDE 2000
> Before running Setup, identify the version of the MSDE 2000 instance that
> is being upgraded. If the version of MSDE 2000 is already at or greater than
> SP4, you do not need to install SP4.
> To identify the installed version of MSDE 2000:
> 1.. Execute one of the following queries against an instance of the
> database engine by using isql, osql, or Query Analyzer.
> a.. SELECT SERVERPROPERTY('ProductLevel')
>
> b.. SELECT @.@.VERSION
>
> c.. SELECT SERVERPROPERTY('ProductVersion')
> 2.. Find out your version of MSDE by means of the following table. SQL
> Server 2000 Version and Level @.@.VERSION Product Level
> SQL Server 2000 Original Release 8.00.194 RTM
> Desktop Engine SP1 8.00.384 SP1
> Desktop Engine SP2 8.00.534 SP2
> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
> MSDE 2000 SP4 8.00.2039 SP4
> Chris
> <tim@.tcsys.com> wrote in message
> news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> > Thanks for replying, Chris.
> >
> > I know almost nothing about SQL server, but, that being said, I'm an
> > otherwise competent MS net admin.
> >
> > This particular box has an MSDE engine installed by an not-profit
> > financial application. The management of this app is hands-off, under
> > the control of the vendor.
> >
> > The thing is, the same server is also our Backup Exec box. Backup Exec
> > was configured to use the same SQL instance as the financial app.
> > That's not unusual; the use of an existing SQL or MSDE instance on the
> > same box is the default installation setting for Backup Exec.
> >
> > But lately we've been having some trouble with Backup Exec. And
> > wouldn't you know it? Some mismatched MDAC files turned up in the
> > course of investigation, and now Veritas/Symantec technical support is
> > insisting upon having the information in the OP before proceeding
> > further with the case.
> >
> > So to answer your question: Knowing that this is an MSDE installation,
> > I was able to Google up this command line...
> > osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> > ...but I'm prompted for a password which I do not believe that I
> > posses.
> >
> > I've tried running it with the local administrator account and the
> > domain administrator account. No luck.
> >
> > Believe me, your continued assistance is appreciated!
> >
>
>|||Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
the Premium edition that includes full blown SQL2000 SP4.
If this is SP1 then my previous note about MDAC applies.
Chris
"Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...
> Chris,
> This thread speaks to a problem I created on our SBS 2003 with MDAC now
> having 5 mismatched file versions and a crippled Veritas BackupExec 10,
> not
> to mention the other problems this MDAC issue is causing. I lost RAS
> yesterday (related? who knows!) and I can no longer access our Exchange
> Server through the Web access for Outlook 2003.
> I really messed things up and need help to get the correct MDAC files
> restored. I used the cc.exe. Component Checker from MS to test the
> installed
> version against the expected file versions.
> Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
> HELP!
> Chris
> "Chris Wood" wrote:
>> Tim,
>> If you are using an Windows administrator id I think that use can use
>> the -E
>> rather than -U parameter. This should not ask for a password.
>> From the MSDE SP4 readme
>> 1.5 Verify the Version of Microsoft Data Access Components
>> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
>> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
>> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
>>
>> b.. Computers that run Windows XP or Windows Server 2003 are not
>> upgraded
>> to MDAC 2.8 SP1. If your system requires any of the fixes included in
>> MDAC
>> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1
>> to
>> obtain MDAC 2.8 SP2.
>>
>> c.. MDAC 2.8 SP1 is not installed on computers that already have
>> installed
>> an equal or later version of MDAC.
>> d..
>> e.. 1.6 Identify the Current Version of MSDE 2000
>> Before running Setup, identify the version of the MSDE 2000 instance
>> that
>> is being upgraded. If the version of MSDE 2000 is already at or greater
>> than
>> SP4, you do not need to install SP4.
>> To identify the installed version of MSDE 2000:
>> 1.. Execute one of the following queries against an instance of the
>> database engine by using isql, osql, or Query Analyzer.
>> a.. SELECT SERVERPROPERTY('ProductLevel')
>>
>> b.. SELECT @.@.VERSION
>>
>> c.. SELECT SERVERPROPERTY('ProductVersion')
>> 2.. Find out your version of MSDE by means of the following table.
>> SQL
>> Server 2000 Version and Level @.@.VERSION Product Level
>> SQL Server 2000 Original Release 8.00.194 RTM
>> Desktop Engine SP1 8.00.384 SP1
>> Desktop Engine SP2 8.00.534 SP2
>> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
>> MSDE 2000 SP4 8.00.2039 SP4
>> Chris
>> <tim@.tcsys.com> wrote in message
>> news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
>> > Thanks for replying, Chris.
>> >
>> > I know almost nothing about SQL server, but, that being said, I'm an
>> > otherwise competent MS net admin.
>> >
>> > This particular box has an MSDE engine installed by an not-profit
>> > financial application. The management of this app is hands-off, under
>> > the control of the vendor.
>> >
>> > The thing is, the same server is also our Backup Exec box. Backup Exec
>> > was configured to use the same SQL instance as the financial app.
>> > That's not unusual; the use of an existing SQL or MSDE instance on the
>> > same box is the default installation setting for Backup Exec.
>> >
>> > But lately we've been having some trouble with Backup Exec. And
>> > wouldn't you know it? Some mismatched MDAC files turned up in the
>> > course of investigation, and now Veritas/Symantec technical support is
>> > insisting upon having the information in the OP before proceeding
>> > further with the case.
>> >
>> > So to answer your question: Knowing that this is an MSDE installation,
>> > I was able to Google up this command line...
>> > osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
>> > ...but I'm prompted for a password which I do not believe that I
>> > posses.
>> >
>> > I've tried running it with the local administrator account and the
>> > domain administrator account. No luck.
>> >
>> > Believe me, your continued assistance is appreciated!
>> >
>>|||Chris (Wood),
Are you asking about my server issue or the one from Tim? We are not at SP1
for our SBS 2003 yet because the server would not allow Windows Update to
properly run much less update it's components. I have all 5 of the Microsoft
specified downloads for SBS 2003 SP1 downloaded as per an article I read on
the SBS MS site. I was planning to do some more reading on this before trying
to apply them and was hoping that would fix my browser issue that kept it
from running Windows Update properly.
Frankly this server was a walking abortion from the get go with the company
that originally installed it doing a very poor job. I band-aided everything I
could safely do to even get it to run without daily unexpected re-boots. I
know that was putting off the inevidable, but the company needed to get back
to daily operations after 30+ days of dissruption caused by this "other"
outside computer company. We have since severed ties with them.
Anyway, we are running with only the original installation of SBS 2003, some
security patches in place and not much else. I also wanted to update the
exchange server to SP1 (this is part of the process I hope to complete once I
fix my MDAC issues).
Since I last posted, I tossed in my towel on this and have a engineer coming
in this morning from a group that has been trying to get our business for
some time now. I hope he will know what to do to fix this MDAC problem.
But any input you can offer will be good. Also, we are running the standard
version of SBS 2003, not the premium, thus the SQL is only that MSDE2000,
which I am growing to hate by the minute. I would have ponyed up the money
for the premium if I where actually working here when they were forced to get
a new server back in December 2004. (The old server was a Netware server that
this same outside computer company supported, broke and then said it's better
to scrap that server and replace it with the SBS 2003 they installed - This
Machine. We all know how well a job they did on that too!)
Sorry to rant. It's been a long week and I am stressed out.
Chris W.
"Chris Wood" wrote:
> Is this SBS 2003 SP1? It looks like it includes MSDE2000 SP4 unless you have
> the Premium edition that includes full blown SQL2000 SP4.
> If this is SP1 then my previous note about MDAC applies.
> Chris
> "Chris Williams" <Chris Williams@.discussions.microsoft.com> wrote in message
> news:BE841E75-8D2C-4EE1-B2E7-D4BE9EAD417E@.microsoft.com...
> > Chris,
> >
> > This thread speaks to a problem I created on our SBS 2003 with MDAC now
> > having 5 mismatched file versions and a crippled Veritas BackupExec 10,
> > not
> > to mention the other problems this MDAC issue is causing. I lost RAS
> > yesterday (related? who knows!) and I can no longer access our Exchange
> > Server through the Web access for Outlook 2003.
> >
> > I really messed things up and need help to get the correct MDAC files
> > restored. I used the cc.exe. Component Checker from MS to test the
> > installed
> > version against the expected file versions.
> >
> > Veritas/Symantec will not proceed with assistance until I get MDAC fixed.
> >
> > HELP!
> >
> > Chris
> >
> > "Chris Wood" wrote:
> >
> >> Tim,
> >>
> >> If you are using an Windows administrator id I think that use can use
> >> the -E
> >> rather than -U parameter. This should not ask for a password.
> >>
> >> From the MSDE SP4 readme
> >>
> >> 1.5 Verify the Version of Microsoft Data Access Components
> >> MSDE 2000 SP4 setup determines whether to upgrade an installed version of
> >> Microsoft Data Access Components (MDAC) to MDAC 2.8 SP1:
> >>
> >> a.. Computers that run Windows 2000 are upgraded to MDAC 2.8 SP1.
> >>
> >>
> >> b.. Computers that run Windows XP or Windows Server 2003 are not
> >> upgraded
> >> to MDAC 2.8 SP1. If your system requires any of the fixes included in
> >> MDAC
> >> 2.8 SP1, upgrade your system to Windows XP SP2 or Windows Server 2003 SP1
> >> to
> >> obtain MDAC 2.8 SP2.
> >>
> >>
> >> c.. MDAC 2.8 SP1 is not installed on computers that already have
> >> installed
> >> an equal or later version of MDAC.
> >> d..
> >> e.. 1.6 Identify the Current Version of MSDE 2000
> >> Before running Setup, identify the version of the MSDE 2000 instance
> >> that
> >> is being upgraded. If the version of MSDE 2000 is already at or greater
> >> than
> >> SP4, you do not need to install SP4.
> >>
> >> To identify the installed version of MSDE 2000:
> >>
> >> 1.. Execute one of the following queries against an instance of the
> >> database engine by using isql, osql, or Query Analyzer.
> >> a.. SELECT SERVERPROPERTY('ProductLevel')
> >>
> >>
> >> b.. SELECT @.@.VERSION
> >>
> >>
> >> c.. SELECT SERVERPROPERTY('ProductVersion')
> >> 2.. Find out your version of MSDE by means of the following table.
> >> SQL
> >> Server 2000 Version and Level @.@.VERSION Product Level
> >> SQL Server 2000 Original Release 8.00.194 RTM
> >> Desktop Engine SP1 8.00.384 SP1
> >> Desktop Engine SP2 8.00.534 SP2
> >> Desktop Engine SP3, SP3a, or MSDE 2000 Release A. 8.00.760 SP3
> >> MSDE 2000 SP4 8.00.2039 SP4
> >>
> >> Chris
> >> <tim@.tcsys.com> wrote in message
> >> news:1123100308.823774.310400@.g49g2000cwa.googlegroups.com...
> >> > Thanks for replying, Chris.
> >> >
> >> > I know almost nothing about SQL server, but, that being said, I'm an
> >> > otherwise competent MS net admin.
> >> >
> >> > This particular box has an MSDE engine installed by an not-profit
> >> > financial application. The management of this app is hands-off, under
> >> > the control of the vendor.
> >> >
> >> > The thing is, the same server is also our Backup Exec box. Backup Exec
> >> > was configured to use the same SQL instance as the financial app.
> >> > That's not unusual; the use of an existing SQL or MSDE instance on the
> >> > same box is the default installation setting for Backup Exec.
> >> >
> >> > But lately we've been having some trouble with Backup Exec. And
> >> > wouldn't you know it? Some mismatched MDAC files turned up in the
> >> > course of investigation, and now Veritas/Symantec technical support is
> >> > insisting upon having the information in the OP before proceeding
> >> > further with the case.
> >> >
> >> > So to answer your question: Knowing that this is an MSDE installation,
> >> > I was able to Google up this command line...
> >> > osql.exe -U administrator -Q "USE master SELECT @.@.version" -p
> >> > ...but I'm prompted for a password which I do not believe that I
> >> > posses.
> >> >
> >> > I've tried running it with the local administrator account and the
> >> > domain administrator account. No luck.
> >> >
> >> > Believe me, your continued assistance is appreciated!
> >> >
> >>
> >>
> >>
>
>sql
mdac error
Hi,
I have updated my Win98 SE with MDAC 2.7 program and checked
it with component checker (cc.exe) from Microsoft website. Found a warning
that is as following:
Item Name,Item Type,ErrorString,Status
MSADCO.DLL,COM,Unknown Class ID =
{9381d8f1-0288-11d0-9501-00aa00b911a5},Warning
And I attached the screen. Please tell me the impact and any solution?
Thanks.
SupernovaThat dll may be a browser related ADO component?? are you having some kind of issue with web applications (that interface to your database) on the workstation?|||Originally posted by DBA
That dll may be a browser related ADO component?? are you having some kind of issue with web applications (that interface to your database) on the workstation?
Actually not web application. It's a ODBC/SQL server application running at workstation.|||Have you tried running comcheck with switch 'd' (this is a reconfiguration option) ? Have you noticed any problems ? The screen attachment never made it.
I have updated my Win98 SE with MDAC 2.7 program and checked
it with component checker (cc.exe) from Microsoft website. Found a warning
that is as following:
Item Name,Item Type,ErrorString,Status
MSADCO.DLL,COM,Unknown Class ID =
{9381d8f1-0288-11d0-9501-00aa00b911a5},Warning
And I attached the screen. Please tell me the impact and any solution?
Thanks.
SupernovaThat dll may be a browser related ADO component?? are you having some kind of issue with web applications (that interface to your database) on the workstation?|||Originally posted by DBA
That dll may be a browser related ADO component?? are you having some kind of issue with web applications (that interface to your database) on the workstation?
Actually not web application. It's a ODBC/SQL server application running at workstation.|||Have you tried running comcheck with switch 'd' (this is a reconfiguration option) ? Have you noticed any problems ? The screen attachment never made it.
MDAC Component Checker
I am on a win 2003 server and have run the component
checker and found 2 errors. The files obdcbcp.dll and
sqlsrv32.dll have mismatch errors. There errors say
expecting version 2000.85.1022.0; but the problem is that
I have 2000.85.1025.0
How can I fix this?
Thanks in advance,
Stewart
It sounds like you have installed MS04-003 to thsi system. The sqlsrv32.dll
and odbcbcp.dll from that patch are version 2000.85.1025.0.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||Stewart,
I have exactly same problem, what did you do to fix it?
Thanks
Regards
Kasba
checker and found 2 errors. The files obdcbcp.dll and
sqlsrv32.dll have mismatch errors. There errors say
expecting version 2000.85.1022.0; but the problem is that
I have 2000.85.1025.0
How can I fix this?
Thanks in advance,
Stewart
It sounds like you have installed MS04-003 to thsi system. The sqlsrv32.dll
and odbcbcp.dll from that patch are version 2000.85.1025.0.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||Stewart,
I have exactly same problem, what did you do to fix it?
Thanks
Regards
Kasba
MDAC Component Checker
I am on a win 2003 server and have run the component
checker and found 2 errors. The files obdcbcp.dll and
sqlsrv32.dll have mismatch errors. There errors say
expecting version 2000.85.1022.0; but the problem is that
I have 2000.85.1025.0
How can I fix this?
Thanks in advance,
StewartIt sounds like you have installed MS04-003 to thsi system. The sqlsrv32.dll
and odbcbcp.dll from that patch are version 2000.85.1025.0.
Rand
This posting is provided "as is" with no warranties and confers no rights.|||Stewart,
I have exactly same problem, what did you do to fix it?
Thanks
Regards
Kasba
vkasba
---
Posted via http://www.mcse.ms
---
View this thread: http://www.mcse.ms/message744871.html
checker and found 2 errors. The files obdcbcp.dll and
sqlsrv32.dll have mismatch errors. There errors say
expecting version 2000.85.1022.0; but the problem is that
I have 2000.85.1025.0
How can I fix this?
Thanks in advance,
StewartIt sounds like you have installed MS04-003 to thsi system. The sqlsrv32.dll
and odbcbcp.dll from that patch are version 2000.85.1025.0.
Rand
This posting is provided "as is" with no warranties and confers no rights.|||Stewart,
I have exactly same problem, what did you do to fix it?
Thanks
Regards
Kasba
vkasba
---
Posted via http://www.mcse.ms
---
View this thread: http://www.mcse.ms/message744871.html
Monday, February 20, 2012
Max() problem
Max () is driving me batty
MasterPart Component EFFDATE QTYPER
1111 zzzz 2006-10-5 20
1111 zzzz 2007-9-1 0
1111 zaza 2007-9-1 20
I need to return components that are active. In the above table the only item that should return is the component zaza (In other words on Oct 5 2006 a part(zzzz) was added, however on Sept 1 2007 it was zero'd out and a new part(zaza) was added)
By getting the Max(EFFDATE) from the table I need to then see if the QTYPER is greater than 0 if not then I do not need it to show.
Will this work?
SELECT MasterPart,MAX(EFFDATE)as EFFDATE, QTYPER
FROM partDates
GROUPBY MasterPart, QTYPER
HAVING QTYPER>0
Subscribe to:
Posts (Atom)