MDAC reinstall under Win XP Sp2

Hello Guys!
I have a corrupted MDAC Installation on a Windows XP Sp2 Client.
The Application we use responds with the message "provider not found" for a
MS SQL 2000 Connection.
Poorly i cannot just install MDAC again since the setup denies that under
Win XP Sp2.
Is there any way to reinstall MDAC or heal this corrupt part? A reinstall of
the Service Pack did not solve it.
Greetings,
Daniel Guenther
Hi Daniel,
Thanks for your post.
From your descriptions, I understood that you would like to reinstall MDAC
in Windows XP SP2 box. Have I understood you? Correct me if I was wrong.
Based on my scope, the reason why you cannot complete the installation was
that Windows XP Service Pack 2 comes with MDAC 2.81 already so that it is
not necessary for you to install it.
Anyway, if you want to reinstall MDAC manually, you could follow the steps
below (anyway, I will not recommend to do so if there is nothing wrong with
your MDAC)
Navigate to the folder c:\windows\inf. Right-click on MDAC.INF and click
"install."
It will recopy the mdac files and reregister some of the basic registry
entries.
It will ask for the Windows XP CDROM as well as the Windows XP SP2 CDROM.
Some other pointers here:
- When it asks for the Windows XP SP2 CDROM, you will need to point it over
to c:\windows\servicepackfiles\i386.
- When it asks for the Windows XP CD, you will need to have the cd in the
drive and point it over to D:\i386 (assuming D is the cdrom drive.)
- If you do not have the Windows XP CD, you may have an i386 folder on
drive C (if the OEM manufacturer put it there.) In this case point it over
to C:\i386.
If all aboves doesn't resolve your problem, please paste your
c:\WINDOWS\dasetup.log here and I would love to make further research.
Thank you for your patience and corporation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Get Secure! - http://www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Hello Michael!
Thanks alot for your quick answer.
Poorly your tip didn't help me much.
I have no idea why, but this setup is not able to copy any single file
during the installation.
I only get the file query dialog again and again.
NTFS Permissions are checked, i am admin and can write/read from
source/destination dir.
The files to copy are definitly in the windows\servicepackfiles\i386
directory.
To be true, I am lost actually... ;)
The logfile btw. does not contain a single entry of my actual try to install
mdac.
So, you have probably another hint for me? ;-)
Greetings,
Daniel Guenther
|||Hi Daniel,
Based on my scope, the file query dialog box comes again and again only
when incorrect file path was specified. Could you confirm you had use the
right ones?
Another workaround is reinstall Windows XP Service Pack 2. It seems you had
tried this, but please try again. Make sure to follow the instuctions in KB
below to reomve first.
How to remove Windows XP Service Pack 2 from your computer
http://support.microsoft.com/kb/875350/EN-US
And here is some KB for further troubleshooting that may help
Component Checker: Diagnose problems and reconfigure MDAC installations
http://support.microsoft.com/kb/307255/EN-US/
How To MDAC Setup Troubleshooting Guide
http://support.microsoft.com/kb/232060/EN-US/
Thank you for your patience and corporation. If you have any questions or
concerns, don't hesitate to let me know. We are always here to be of
assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Get Secure! - http://www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||I am having a similar problem with MDAC after the installation of XP
SP2. I have run the MS Component Checker tool in its default mode and
it produces an error message stating that you must select a specific
version to check against. However MDAC 2.81 XP SP2 is not listed, only
a the previous Mdac 2.7 XP SP1 and this returns a whole list of
errors. If XP SP2 includes MDAC 2.81 then presumably previous versions
are not required. Is there any way to remove all the old MDAC
components, registry entries etc with a clean install of XP?
Thanks
Dave
v-mingqc@.online.microsoft.com ("Michael Cheng [MSFT]") wrote in message news:<v3oASSkwEHA.3956@.cpmsftngxa10.phx.gbl>...
> Hi Daniel,
> Based on my scope, the file query dialog box comes again and again only
> when incorrect file path was specified. Could you confirm you had use the
> right ones?
> Another workaround is reinstall Windows XP Service Pack 2. It seems you had
> tried this, but please try again. Make sure to follow the instuctions in KB
> below to reomve first.
> How to remove Windows XP Service Pack 2 from your computer
> http://support.microsoft.com/kb/875350/EN-US
> And here is some KB for further troubleshooting that may help
> Component Checker: Diagnose problems and reconfigure MDAC installations
> http://support.microsoft.com/kb/307255/EN-US/
> How To MDAC Setup Troubleshooting Guide
> http://support.microsoft.com/kb/232060/EN-US/
> Thank you for your patience and corporation. If you have any questions or
> concerns, don't hesitate to let me know. We are always here to be of
> assistance!
>
> Sincerely yours,
> Michael Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Get Secure! - http://www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
|||Hi Daniel,
Have you tried to uninstall XP SP2 and then reinstall it? Does this resolve
your issues? I am just checking on your progress regarding the information
that was sent you! I wonder how the testing is going. If you encounter any
difficulty, please do not hesitate to let me know. Please post here and let
me know the status of your issue. Without your further information, it's
very hard for me to continue with the troubleshooting.
Looking forward to hearing from you soon
Thank you for your patience and corporation. If you have any questions or
concerns, don't hesitate to let me know. We are always here to be of
assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Get Secure! - http://www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

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...
>
>

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...
>
>

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

MDAC 2.8 Issues?

Most of our Windows 98 SE workstations that are running
MDAC 2.8 have an issue when posting a transaction against
a SQL Server 2000 SP2 database. OLE DB Provider for SQL
Server is the database connector and the application
making the call is coded in Visual Basic 6.1.

The client sees this error returned as an "Runtime 6 -
Overflow Error" on the Visual Basic end as reported by the
OLE DB Provider. Below is a snippet as taken from the SQL
Server Profiler trace:

declare @.P1 int
set @.P1=180150062
declare @.P2 int
set @.P2=2
declare @.P3 int
set @.P3=4
declare @.P4 int
set @.P4=-1
exec sp_cursoropen @.P1 output, N'SELECT TblJobs.[Control
Status Code], TblJobs.[Sales Date], TblJobs.[Promise
Date], TblCust.Last, TblCust.First, TblCust.MI, TblCust.
[Home Phone] FROM TblCust RIGHT JOIN TblJobs ON TblCust.
[Customer ID] = TblJobs.[Customer ID] WHERE TblJobs.
[Control Number] = 00801328', @.P2 output, @.P3 output, @.P4
output
select @.P1, @.P2, @.P3, @.P4

exec sp_cursorfetch 180150062, 32, 1, 1

exec sp_cursorclose 180150062

Error: 2809, Severity: 18, State: 1

Error: 16945, Severity: 16, State: 1

declare @.P1 int
set @.P1=0
declare @.P2 int
set @.P2=229378
declare @.P3 int
set @.P3=294916
declare @.P4 int
set @.P4=0
exec sp_cursoropen @.P1 output, N'exec TblTransactions',
@.P2 output, @.P3 output, @.P4 output
select @.P1, @.P2, @.P3, @.P4

Error: 2809, Severity: 18, State: 1

Error: 16945, Severity: 16, State: 1

Any suggestions? Would using a stored procedure benefit
any? Are there known issues with MDAC 2.8 operating in
this manner? When I rollback to MDAC 2.5 or 2.6 the
operation goes through successfully. I don't relish
rolling back a decent number of client workstations seeing
other MDAC-dependent applications work fine. Unfortunately
I don't have the VB source code to post, so I might be
grasping at straws by posting here.

Any help would be appreciated!Howdy

MDAC 2.8 should really be run against SQL 2000 SP3A - nothing less.
You are running SQL 2000 SP2.

Seems to be lots of problems with SQL 2000 and MDAC & VB ( 6 & .NET )

Cheers,

SG|||I just tested this out by upgrading my local MSDE to sp3a. Restarted and tried the same transaction type and it failed just the same. I really am dreading rolling back all of these workstations, especially since just this one custom app is the one giving me trouble. Wish I myself was a VB programmer so I could dig into things for myself!

Can't imagine something as simple as trying to append a row to an existing set could offer problems. And if MDAC 2.8 is the culprit (since rolling back seems to fix things) I can't imagine no one else piping up about odd MADC 2.8 behavior. Oh well...*sigh*|||Howdy,

It might be worth trying setting nocount on in the sprocs to see what that does...

It may be the "chatter" that the app produces may be causing buffer overflows perhaps. I found setting nocount to on helps with some apps

Cheers,

SG.

MDAC 2.8 Fatal Setup Error. This setup does not support installing on this operating system

I have XP Pro SP2 with MDAC 2.8.1022. It had a problem so I tried to reinstall MDAC and got a Fatal Setup Error. This setup does not support installing on this operating system. I downloaded MDAC 2.8 1177 and get the same error.

I thought of uninstalling/reinstalling SP2, but this is a 2 month old Dell Latitude 610 with factory installed XP. There is no Windows Service Pack 2 option listed in the Control Panel > Add/Remove Programs.

There's some other strange things, so I wonder if they are related.

1) I have Paul set up as an administrator account. Some folders like MSSQL show that account with no permissions. I grant all the permissions to Paul for that folder. I come back later and the permissions are gone.

2) I deleted 20 files in Explorer, but 7 of them did not go away. I deleted those 7 again and they instatnly reappeared. I deleted those 7 again and then they finally went away.

3) I get a slow reaction time for things like Windows Explorer and opening and closing programs. This is suprising since it has 2 gig of RAM and 2.3 Gig processor. Could it be a memory handling problem that's causing OS problems. Probably, the memory didn't handle the OS installation well and the whole system is compromised now.

I'm having the same problem on XP Sp2 trying to re-install MDAC.

Thought I'd try re-installing MDAC since my system errors out when I try to register DLL files.

|||

I've seen this error during MDAC installation on XP SP2 as well. I was able to get around it by changing the Compatibility Properties of the mdac installation file to Win NT. It then installs OK.

|||

Chnaces are the files did go away for an instant but they are on the system recovery list and XP replaced them.

|||

I have XP Pro SP2 . It had a problem so I tried to install ADO.Net (MDAC Version 2.8 SP1 ) many times and reload it from download.microsoft.com. I couldn't install on my computer. I get the Fatal Setup Error "This setup does not support installing on this operating system". How can I solve this problem ?

|||

I could not overcome the problem.. I finally did erased the drive and reinstalled windows.

Paul

|||Windows XP comes pre-installed with MDAC you should not install the standalone MDAC installer on Windows XP. If you have a problem with the MDAC install on XP then just run a repair install of XP this will reinstall the MDAC that XP ships with.|||

I had a similar experience. Two possible options can be used to allow XP to repair the entries or force the install without having to repair the XP installation.

1. To repair your MDAC installation. Found this solution on the web that works. Have your XP SP2 install disk handy. Go to and find c:\windows\inf\mdac.inf. Right click on the .inf file and pick Install. It will attempt to reinstall the files. Browse to source files on the XP CD. It should install smoothly. It may ask for the handler.reg (in c:\program files\common files\system\msadc\). Restart. Sign in (admin) and then after a few minutes windows update will want to apply the security patch again. You may want to follow up with the SJet update also.

2. To force the installation. Found this one also. XP SP2 will already have the SP1 update applied but has registry corruption (virus after affects). Right click on the MDAC 2.8 SP1 install exe file and select properties. Select the Compatability tab, check the compatability mode box and pick "windows NT" or possibly "Windows 2000". Click apply and run the file again. It should install all the proper files again.

This restored the complete connectivity to databases. In visual studio the data tables did not display properly with a flawed connection. If the access (mdb) tables display properly, then a connection to the SQL database (mdf) - missing tables -is a access/login rights problem. Grant login rights to the user for the database.

|||

John,

#2 works like a charms. Thanks a million.

sql

MDAC 2.8 Fatal Setup Error. This setup does not support installing on this operating system

I have XP Pro SP2 with MDAC 2.8.1022. It had a problem so I tried to reinstall MDAC and got a Fatal Setup Error. This setup does not support installing on this operating system. I downloaded MDAC 2.8 1177 and get the same error.

I thought of uninstalling/reinstalling SP2, but this is a 2 month old Dell Latitude 610 with factory installed XP. There is no Windows Service Pack 2 option listed in the Control Panel > Add/Remove Programs.

There's some other strange things, so I wonder if they are related.

1) I have Paul set up as an administrator account. Some folders like MSSQL show that account with no permissions. I grant all the permissions to Paul for that folder. I come back later and the permissions are gone.

2) I deleted 20 files in Explorer, but 7 of them did not go away. I deleted those 7 again and they instatnly reappeared. I deleted those 7 again and then they finally went away.

3) I get a slow reaction time for things like Windows Explorer and opening and closing programs. This is suprising since it has 2 gig of RAM and 2.3 Gig processor. Could it be a memory handling problem that's causing OS problems. Probably, the memory didn't handle the OS installation well and the whole system is compromised now.

I'm having the same problem on XP Sp2 trying to re-install MDAC.

Thought I'd try re-installing MDAC since my system errors out when I try to register DLL files.

|||

I've seen this error during MDAC installation on XP SP2 as well. I was able to get around it by changing the Compatibility Properties of the mdac installation file to Win NT. It then installs OK.

|||

Chnaces are the files did go away for an instant but they are on the system recovery list and XP replaced them.

|||

I have XP Pro SP2 . It had a problem so I tried to install ADO.Net (MDAC Version 2.8 SP1 ) many times and reload it from download.microsoft.com. I couldn't install on my computer. I get the Fatal Setup Error "This setup does not support installing on this operating system". How can I solve this problem ?

|||

I could not overcome the problem.. I finally did erased the drive and reinstalled windows.

Paul

|||Windows XP comes pre-installed with MDAC you should not install the standalone MDAC installer on Windows XP. If you have a problem with the MDAC install on XP then just run a repair install of XP this will reinstall the MDAC that XP ships with.|||

I had a similar experience. Two possible options can be used to allow XP to repair the entries or force the install without having to repair the XP installation.

1. To repair your MDAC installation. Found this solution on the web that works. Have your XP SP2 install disk handy. Go to and find c:\windows\inf\mdac.inf. Right click on the .inf file and pick Install. It will attempt to reinstall the files. Browse to source files on the XP CD. It should install smoothly. It may ask for the handler.reg (in c:\program files\common files\system\msadc\). Restart. Sign in (admin) and then after a few minutes windows update will want to apply the security patch again. You may want to follow up with the SJet update also.

2. To force the installation. Found this one also. XP SP2 will already have the SP1 update applied but has registry corruption (virus after affects). Right click on the MDAC 2.8 SP1 install exe file and select properties. Select the Compatability tab, check the compatability mode box and pick "windows NT" or possibly "Windows 2000". Click apply and run the file again. It should install all the proper files again.

This restored the complete connectivity to databases. In visual studio the data tables did not display properly with a flawed connection. If the access (mdb) tables display properly, then a connection to the SQL database (mdf) - missing tables -is a access/login rights problem. Grant login rights to the user for the database.

|||

John,

#2 works like a charms. Thanks a million.

MDAC 2.8 Fatal Setup Error. This setup does not support installing on this operating system

I have XP Pro SP2 with MDAC 2.8.1022. It had a problem so I tried to reinstall MDAC and got a Fatal Setup Error. This setup does not support installing on this operating system. I downloaded MDAC 2.8 1177 and get the same error.

I thought of uninstalling/reinstalling SP2, but this is a 2 month old Dell Latitude 610 with factory installed XP. There is no Windows Service Pack 2 option listed in the Control Panel > Add/Remove Programs.

There's some other strange things, so I wonder if they are related.

1) I have Paul set up as an administrator account. Some folders like MSSQL show that account with no permissions. I grant all the permissions to Paul for that folder. I come back later and the permissions are gone.

2) I deleted 20 files in Explorer, but 7 of them did not go away. I deleted those 7 again and they instatnly reappeared. I deleted those 7 again and then they finally went away.

3) I get a slow reaction time for things like Windows Explorer and opening and closing programs. This is suprising since it has 2 gig of RAM and 2.3 Gig processor. Could it be a memory handling problem that's causing OS problems. Probably, the memory didn't handle the OS installation well and the whole system is compromised now.

I'm having the same problem on XP Sp2 trying to re-install MDAC.

Thought I'd try re-installing MDAC since my system errors out when I try to register DLL files.

|||

I've seen this error during MDAC installation on XP SP2 as well. I was able to get around it by changing the Compatibility Properties of the mdac installation file to Win NT. It then installs OK.

|||

Chnaces are the files did go away for an instant but they are on the system recovery list and XP replaced them.

|||

I have XP Pro SP2 . It had a problem so I tried to install ADO.Net (MDAC Version 2.8 SP1 ) many times and reload it from download.microsoft.com. I couldn't install on my computer. I get the Fatal Setup Error "This setup does not support installing on this operating system". How can I solve this problem ?

|||

I could not overcome the problem.. I finally did erased the drive and reinstalled windows.

Paul

|||Windows XP comes pre-installed with MDAC you should not install the standalone MDAC installer on Windows XP. If you have a problem with the MDAC install on XP then just run a repair install of XP this will reinstall the MDAC that XP ships with.|||

I had a similar experience. Two possible options can be used to allow XP to repair the entries or force the install without having to repair the XP installation.

1. To repair your MDAC installation. Found this solution on the web that works. Have your XP SP2 install disk handy. Go to and find c:\windows\inf\mdac.inf. Right click on the .inf file and pick Install. It will attempt to reinstall the files. Browse to source files on the XP CD. It should install smoothly. It may ask for the handler.reg (in c:\program files\common files\system\msadc\). Restart. Sign in (admin) and then after a few minutes windows update will want to apply the security patch again. You may want to follow up with the SJet update also.

2. To force the installation. Found this one also. XP SP2 will already have the SP1 update applied but has registry corruption (virus after affects). Right click on the MDAC 2.8 SP1 install exe file and select properties. Select the Compatability tab, check the compatability mode box and pick "windows NT" or possibly "Windows 2000". Click apply and run the file again. It should install all the proper files again.

This restored the complete connectivity to databases. In visual studio the data tables did not display properly with a flawed connection. If the access (mdb) tables display properly, then a connection to the SQL database (mdf) - missing tables -is a access/login rights problem. Grant login rights to the user for the database.

|||

John,

#2 works like a charms. Thanks a million.

MDAC 2.8 Fatal Setup Error. This setup does not support installing on this operating system

I have XP Pro SP2 with MDAC 2.8.1022. It had a problem so I tried to reinstall MDAC and got a Fatal Setup Error. This setup does not support installing on this operating system. I downloaded MDAC 2.8 1177 and get the same error.

I thought of uninstalling/reinstalling SP2, but this is a 2 month old Dell Latitude 610 with factory installed XP. There is no Windows Service Pack 2 option listed in the Control Panel > Add/Remove Programs.

There's some other strange things, so I wonder if they are related.

1) I have Paul set up as an administrator account. Some folders like MSSQL show that account with no permissions. I grant all the permissions to Paul for that folder. I come back later and the permissions are gone.

2) I deleted 20 files in Explorer, but 7 of them did not go away. I deleted those 7 again and they instatnly reappeared. I deleted those 7 again and then they finally went away.

3) I get a slow reaction time for things like Windows Explorer and opening and closing programs. This is suprising since it has 2 gig of RAM and 2.3 Gig processor. Could it be a memory handling problem that's causing OS problems. Probably, the memory didn't handle the OS installation well and the whole system is compromised now.

I'm having the same problem on XP Sp2 trying to re-install MDAC.

Thought I'd try re-installing MDAC since my system errors out when I try to register DLL files.

|||

I've seen this error during MDAC installation on XP SP2 as well. I was able to get around it by changing the Compatibility Properties of the mdac installation file to Win NT. It then installs OK.

|||

Chnaces are the files did go away for an instant but they are on the system recovery list and XP replaced them.

|||

I have XP Pro SP2 . It had a problem so I tried to install ADO.Net (MDAC Version 2.8 SP1 ) many times and reload it from download.microsoft.com. I couldn't install on my computer. I get the Fatal Setup Error "This setup does not support installing on this operating system". How can I solve this problem ?

|||

I could not overcome the problem.. I finally did erased the drive and reinstalled windows.

Paul

|||Windows XP comes pre-installed with MDAC you should not install the standalone MDAC installer on Windows XP. If you have a problem with the MDAC install on XP then just run a repair install of XP this will reinstall the MDAC that XP ships with.|||

I had a similar experience. Two possible options can be used to allow XP to repair the entries or force the install without having to repair the XP installation.

1. To repair your MDAC installation. Found this solution on the web that works. Have your XP SP2 install disk handy. Go to and find c:\windows\inf\mdac.inf. Right click on the .inf file and pick Install. It will attempt to reinstall the files. Browse to source files on the XP CD. It should install smoothly. It may ask for the handler.reg (in c:\program files\common files\system\msadc\). Restart. Sign in (admin) and then after a few minutes windows update will want to apply the security patch again. You may want to follow up with the SJet update also.

2. To force the installation. Found this one also. XP SP2 will already have the SP1 update applied but has registry corruption (virus after affects). Right click on the MDAC 2.8 SP1 install exe file and select properties. Select the Compatability tab, check the compatability mode box and pick "windows NT" or possibly "Windows 2000". Click apply and run the file again. It should install all the proper files again.

This restored the complete connectivity to databases. In visual studio the data tables did not display properly with a flawed connection. If the access (mdb) tables display properly, then a connection to the SQL database (mdf) - missing tables -is a access/login rights problem. Grant login rights to the user for the database.

|||

John,

#2 works like a charms. Thanks a million.

MDAC 2.8 Fatal Setup Error. This setup does not support installing on this operating system

I have XP Pro SP2 with MDAC 2.8.1022. It had a problem so I tried to reinstall MDAC and got a Fatal Setup Error. This setup does not support installing on this operating system. I downloaded MDAC 2.8 1177 and get the same error.

I thought of uninstalling/reinstalling SP2, but this is a 2 month old Dell Latitude 610 with factory installed XP. There is no Windows Service Pack 2 option listed in the Control Panel > Add/Remove Programs.

There's some other strange things, so I wonder if they are related.

1) I have Paul set up as an administrator account. Some folders like MSSQL show that account with no permissions. I grant all the permissions to Paul for that folder. I come back later and the permissions are gone.

2) I deleted 20 files in Explorer, but 7 of them did not go away. I deleted those 7 again and they instatnly reappeared. I deleted those 7 again and then they finally went away.

3) I get a slow reaction time for things like Windows Explorer and opening and closing programs. This is suprising since it has 2 gig of RAM and 2.3 Gig processor. Could it be a memory handling problem that's causing OS problems. Probably, the memory didn't handle the OS installation well and the whole system is compromised now.

I'm having the same problem on XP Sp2 trying to re-install MDAC.

Thought I'd try re-installing MDAC since my system errors out when I try to register DLL files.

|||

I've seen this error during MDAC installation on XP SP2 as well. I was able to get around it by changing the Compatibility Properties of the mdac installation file to Win NT. It then installs OK.

|||

Chnaces are the files did go away for an instant but they are on the system recovery list and XP replaced them.

|||

I have XP Pro SP2 . It had a problem so I tried to install ADO.Net (MDAC Version 2.8 SP1 ) many times and reload it from download.microsoft.com. I couldn't install on my computer. I get the Fatal Setup Error "This setup does not support installing on this operating system". How can I solve this problem ?

|||

I could not overcome the problem.. I finally did erased the drive and reinstalled windows.

Paul

|||Windows XP comes pre-installed with MDAC you should not install the standalone MDAC installer on Windows XP. If you have a problem with the MDAC install on XP then just run a repair install of XP this will reinstall the MDAC that XP ships with.|||

I had a similar experience. Two possible options can be used to allow XP to repair the entries or force the install without having to repair the XP installation.

1. To repair your MDAC installation. Found this solution on the web that works. Have your XP SP2 install disk handy. Go to and find c:\windows\inf\mdac.inf. Right click on the .inf file and pick Install. It will attempt to reinstall the files. Browse to source files on the XP CD. It should install smoothly. It may ask for the handler.reg (in c:\program files\common files\system\msadc\). Restart. Sign in (admin) and then after a few minutes windows update will want to apply the security patch again. You may want to follow up with the SJet update also.

2. To force the installation. Found this one also. XP SP2 will already have the SP1 update applied but has registry corruption (virus after affects). Right click on the MDAC 2.8 SP1 install exe file and select properties. Select the Compatability tab, check the compatability mode box and pick "windows NT" or possibly "Windows 2000". Click apply and run the file again. It should install all the proper files again.

This restored the complete connectivity to databases. In visual studio the data tables did not display properly with a flawed connection. If the access (mdb) tables display properly, then a connection to the SQL database (mdf) - missing tables -is a access/login rights problem. Grant login rights to the user for the database.

|||

John,

#2 works like a charms. Thanks a million.

mdac 2.6 sp2

Does anyone know any bugs on mdac 2.6 sp2 running on win xp or win98 or win 2000?Do you have to run this version on all 3 operating systems ?

MDAC 2.6 and SQL Server 2000

I have been working on a VB6 app that talks to a SQL Server 2000 (SP2) engine via OLEDB. All works well with the exception of one transaction. The particular a transaction updates two tables via stored procs and then is either committed or rolled back.

I have an weird error where by when the transaction calls the second stored proc the data from the first stored proc is gone. I have put a break point in VB before the second stored proc is executed and the data exists but after execution of the second stored proc the data is gone.

The issue gets more weird becuase the app runs fine on a Win 2k machine with MDAC 2.5 but not with MDAC 2.6. I have other transactions that update via two stored procs but they are fine. I tried the app under MDAC 2.7 and that doesn't work either.

I have no rollbacks or commits in the stored procs. Also worth noting that if I am only upadting the second table by adding 5 rows for example, only the last row will be written.

Any suggestions would be most welcome.RE: Q1 Any suggestions would be most welcome.

A1 Are you quite certain you have tested your applications and results using the same MDAC levels accross the server, and the clients being tested (each time)? (There is an executable utility available to check and verify MDAC version levels.) Some symptoms sound like they may result from isolation level issues, while others sound quite peculiar given the data as presented.|||What is the "weird error" you are receiving ? The data that exists and then is gone - is it stored in a table and then "rolled back" out of the table ? I have attached ms component checker if you are concerned about mdac. You can either extract it or rename is to *.exe and it will extract automatically ( I have to a zip extension on it because exe's are not uploadable).|||A possible simple explanation for the "weird error" as described, is that it might be nothing more than an ordinary dirty read (made before a successful commit). The "when upadting the second table by adding 5 rows for example, only the last row will be written" issue is more peculiar. I've sometimes seen such kinds of things in procedures that use cursors (when "unexpected" conditions exist) and / or errors are not handled well.|||Is each stored procedure doing a commit or rollback (within the stored procedure) ? Can you post the stored procedures ( or a simpler version of what you are doing ) and the vb code ?|||The more I thought about your problem, I remembered a similar situation a couple of weeks ago - take a look at the following post and see if it fits:

post (http://dbforums.com/showthread.php?s=&threadid=554748)|||Hi.
Firstly, thankyou for your help. For reference, I am developing on a MDAC 2.6 machine running windows 2k, sp2, but I have referenced mdac 2.5 in the VB project references. The SQL server is running MDAC 2.6.
I can confirm that the stored procedures do not have any rollbacks, this is all handled by the VB code. The stored proc is called once for each row that is to be updated, as the VB code searches through a grid row by row. If any changes are detected on a row then the stored proc is called to perform the update.Once all rows have been searched and updated (if necessary) then the commit is called. In the event of an error then a rollback is called.
Thanks for your help!|||I would run sql profiler for both the successful and unsuccessful transactions - then look at the two and see what is different. If you don't see an answer within these results, please post the profiler output.|||RE: "I can confirm that the stored procedures do not have any rollbacks, this is all handled by the VB code. The stored proc is called once for each row that is to be updated, as the VB code searches through a grid row by row. If any changes are detected on a row then the stored proc is called to perform the update.Once all rows have been searched and updated (if necessary) then the commit is called. In the event of an error then a rollback is called."

Q1 I'm guessing "this is all handled by the VB code" means the ADO, ODBC, etc., API is making the actual transaction syntax on the Sql Server. That could account for the apparent MDAC related differences you are seeing. The rnealejr suggestion to run sql profiler traces for both the successful and unsuccessful transactions and compare them in minute detail is a very good one.

Q2 Just to clarify, this sounds like a description of a series of transactions (one for each updated row), collectively nested in a single transaction for the entire grid. Is that correct?|||Hi.
I have finally managed to make some progress on this matter. I ran the profiler, with a trace on two different situations, i.e. one which works OK and one which doesn't. I kept things simple and simply traced 1 - a deletion of 1 row, on its own, and 2 - a deletion of 2 rows, which rolls back the first deletion so that only the last worked on is actually committed (deleted). I am not sure how to post the trace files on here properly (forgive me, I am new to the profiler) but the text output is:-

Firstly for the deletion of one row which works..
---
set implicit_transactions on (Visual Basic)
---
declare @.P1 varchar(255) (Visual Basic)
set @.P1='OK'
exec UOM_CHANGE @.P1 output, 1, '108', '108', 'tracetest', 'TRC', '12/31/3000'
select @.P1
---
IF @.@.TRANCOUNT > 0 COMMIT TRAN (Visual Basic)
---

Now secondly the deletion of 2 rows which doesnt work so well....
---
set implicit_transactions on (Visual Basic)
---
declare @.P1 varchar(255) (Visual Basic)
set @.P1='OK'
exec UOM_CHANGE @.P1 output, 1, '108', '108', 'trace test 1', 'TRC1', '12/31/3000'
select @.P1
---
SET NO_BROWSETABLE ON (Visual Basic) *
---
SET FMTONLY ON EXEC UOM_CHANGE ' ',0,' ',' ',' ',' ',' ' SET FMTONLY OFF (Visual Basic) *
---
set fmtonly off (Visual Basic) *
---
SET NO_BROWSETABLE OFF (Visual Basic) *
---
declare @.P1 varchar(255) (Visual Basic)
set @.P1='OK'
exec UOM_CHANGE @.P1 output, 1, '109', '109', 'trace test 2', 'TRC2', '12/31/3000'
select @.P1
---
IF @.@.TRANCOUNT > 0 COMMIT TRAN (Visual Basic)
---

Now then, the only difference between the two (apart from of course that the stored proc is called twice in the second trace) are the four operations that I have highlighted above with an asterisk. From reading MSDN it would seem that there is a known bug that a patch is available for, so I will need to look into this further.
Please see this article, ref Q281633

http://support.microsoft.com/default.aspx?scid=KB;en-us;q281633

Our customers build is MDAC 2.5 so we must code to their requirements, but possible the MDAC 2.6 service pack may work. Watch this space!
Thanks for your help, its proven very useful.|||Bingo ! Are you running the original version of mdac 2.6 (no service packs) ? If so, then you hit the nail on the head. Actually, I ran into this problem a few months ago - once I saw your profiler with the set fmtonly - it reminded me.sql

MDAC 2.1 / MDAC 2.53

HI,
SQL Server 7.0 (sp4)
Production machine : SQL Server 7.0 (sp4) Entreprise Edition on NT
--> MDAC 2.1,2 sp2
Test machine : SQL Server 7.0 (sp4) Standard Edition on Windows
2000 --> MDAC 2.53
I would like my Test machine be like my Production Machine.
In others words, I would like to change from MDAC 2.53 to MDAC 2.1.2 sp2 on
my Test machine.
Is it possible ? If yes, how can I do that ? (with Mdac_typ.exe ?)
Thank you
DannyDanny,
MDAC is a system component on Windows 2000 and XP and 2003. You cannot
removed it and I am sure that you cannot downgrade it from 2.5. MDAC 2.5 has
problems with DTS when connecting to MDAC 2.1. So you are better off
upgrading your server level to be the same as the workstation.
Chris Wood
Alberta Department of Energy
CANADA
"Danny Presse" <dpresse@.congresmtl.com> wrote in message
news:uwczaaWTDHA.2280@.TK2MSFTNGP12.phx.gbl...
> HI,
> SQL Server 7.0 (sp4)
> Production machine : SQL Server 7.0 (sp4) Entreprise Edition on NT
> --> MDAC 2.1,2 sp2
> Test machine : SQL Server 7.0 (sp4) Standard Edition on Windows
> 2000 --> MDAC 2.53
> I would like my Test machine be like my Production Machine.
> In others words, I would like to change from MDAC 2.53 to MDAC 2.1.2 sp2
on
> my Test machine.
> Is it possible ? If yes, how can I do that ? (with Mdac_typ.exe ?)
> Thank you
> Danny
>

MBSA and MSXML 2.6

Dear All,
MBSA is saying that I currently have MSXML 2.6 SP2, and that I should
upgrade to SP3. When I did a search on the net, not only is SP3 not
publicly available, it is also included in MS SQL 2000 SP3 that I
already have installed.
How come I am still getting these errors from MBSA despite my servers
having MS SQL 2000 SP3 installed?
Is there a way to manually check my version of MSXML 2.6?
Has anyone had a similar problem?
Thanks.
Aramid"Aramid" <aramid@.hotmail.com> wrote in message
news:63drc112j512d4dntnt2t5q3butk2v51h3@.
4ax.com...
> Dear All,
> MBSA is saying that I currently have MSXML 2.6 SP2, and that I should
> upgrade to SP3. When I did a search on the net, not only is SP3 not
> publicly available, it is also included in MS SQL 2000 SP3 that I
> already have installed.
> How come I am still getting these errors from MBSA despite my servers
> having MS SQL 2000 SP3 installed?
> Is there a way to manually check my version of MSXML 2.6?
This may seem funny but it's no joke: the only KB article I could find, for
checking the XML version called by IE was to get filemon.exe from the
SysInternals.com site, open an XML file with IE, locate the reference to
msxml?.dll in filemon output, and get its properties to check its version.
Here's the article, it's a scream:
http://support.microsoft.com/defaul...kb;en-us;296647
This one is also an interesting read, and it contains links to the how-to
for upgrading your installed parser:
http://support.microsoft.com/defaul...kb;en-us;269238
-Mark

> Has anyone had a similar problem?
> Thanks.
> Aramid