April 6, 2005 at 2:37 pm
Hello Listers,
Do you know how MDAC works? What I mean is : Are MDAC versions cumulatives?
If I run the MDAC checker on my PC, I can see that there is multiples MDAC versions installed.
Can I uninstall the old versions?
The way it works (keeping old version) could lead to unreproductible behavior. If the same program is executed on another PC having just the latest MDAC version comparaing to be executed on a machine having MDAC 2.1 thru 2.8 sp1.
Am I rigth in this reasoning?
Best regards,
Carl
April 6, 2005 at 11:38 pm
According to MSoft you can't uninstall MDAC components (they've obviously never heard of the delete key)
But it can be useful to have the old ones hanging around for programs that expect the X version to be available.
If you do write an app (typically .net/vb etc) it will use the latest version and you have to make sure the MDAC's are updated on the the target - otherwise the app might give "cannot find xxxxx" errors
Usually, an installer program will see MDAC as a required installation...
Msoft states that the latest MDACs are always backward compatible but I have seen this compatibility fail many times.
Cheers,
DB
The systems fine with no users loggged in. Can we keep it that way ?br>
April 7, 2005 at 5:08 am
MDAC is just a set of *.dll files that live in the windows\system32 folder. These are the program libraries for ADO, ADOX, JSO, etc. When you install a later version of MDAC it overwrites the dlls with the newer versions and then 'registers' them using regsvr32.exe. But it doesn't unregister the previous versions first. You only ever have one version of MDAC on your computer (in the windows\system32 folder), but there may be multiple registry entries for all the previous versions. Only the latest versions of the dlls will be used but they are supposed to be backward compatible.
In other words, when you install a computer program (e.g. Enterprise manager) that was developed to access SQL server using ADO, for instance, (using ADO in MDAC 2.5), MDAC 2.5 will be included in the installation program. But, if you already have a later version of MDAC installed on your computer (MDAC 2.7 comes as standard with Windows xp) the MDAC on the installation disk won't overwrite later versions already on the PC. But the fact that the later versions of MDAC are backwards compatible means that the program should still work.
Just look at the latest version number you have got. That is the only one that is being used.
Peter
April 7, 2005 at 6:21 am
Thank's for your explanation Db and Peters.
We have an unreproductible problem (Unmanaged dll calling a managed dll using ADO.NET and the programs never return... but take between 0 and 6% of the CPU again and again) at one of our client site and we are searching different ways: Mdac, Version of the .NET Framwork installed, .NET security, security, ...
Best regards,
Carl
April 18, 2005 at 8:59 am
I think that you can remove MDAC using a "comcheck" program which is available on the Microsoft website.
Component Checker: Diagnose problems and reconfigure MDAC installations
http://support.microsoft.com/default.aspx?scid=kb;en-us;307255
"Note: Removing or replacing some of the MDAC components from the operating system can cause data loss and unpredictable results. MDAC components are system components; they are installed as part of the operating system on computers that are running Windows Millennium Edition, Windows 2000, and later versions of Windows. Therefore, you cannot manually modify or remove MDAC from these operating systems."
April 18, 2005 at 9:43 am
What I find useful with problem DLLs is using Dependency Walker to see what version of DLLs are called by the problem DLL. Then either copy those client DLLs onto your test PC to reproduce the problem, or copy your version of the DLLs to the client's PC to see if it fixes the problem.
I had a similar problem once using ADO (not ado.net) at my current client site. There is a problem with connections occasionaly dropping for no reason (have tested everything and changed all the network switches, etc). Was getting recordsets using ADO in Asychronous mode. If the connection dropped, my program would start using 100% of the CPU because it was looping around waiting for a reply from the server. Changing it to Synchronous mode stopped my system monopolising the client's PC when there was a problem. If the recordset open timed out with a connection problem, I just closed and then re opened the connection and try to retrieve the recordset again - but this only works if using OLEDB drivers and setting the SQL Server recordset "Preserve On Commit" and "Preserve on abort" properties to true.
Hope this helps
Peter
April 18, 2005 at 9:49 am
Hello Peter,
In our case, there is not connection at all on the server (but it should).
Yes I know Dependency walker.
We are about to schedule a little trip to the customer's site to debug our apps locally because we have tried many things without succes.
Thanks for your hints,
Carl
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply