Microsoft sql server 2000 desktop engine windows 10

I know of no hacks to get SQL Server 2000 to install on an existing Windows 10 installation. There are probably forces against you from both within the setup program (which looks for certain things on the host system) and within the operating system (which prevents many flavors of older software from getting installed, mostly for security reasons but also compatibility, stability, etc). I have tried in the past and even with compatibility override options I came across the same failures every time.

A couple of ideas:

1. Use a virtual machine. This really is the simplest and most obvious solution. Most (if not all) editions of Windows 10 now support Hyper-V natively; if not, there is always VMWare Workstation (not free) and Oracle VirtualBox (free).
2. Install 2000 then upgrade. Not really practical, especially if you want to use the Windows 10 installation you already have, but if you were doing this from scratch, you could install XP/Vista/Win7, all of which should allow you to install 2000, and then upgrade. Take care, though, because some methods of upgrading to Windows 10 will relegate all of your programs and services to Windows.old, and they won’t run any more.

In either case, firewall the crap out of that thing, because the most recent security patches for 2000 are hard to find, and the ones that I found wouldn’t install anyway…

• Question

• 

  

  0

  
  Sign in to vote
  

  Team,

  Greetings!!

  Microsoft SQL 2000 Desktop Engine is not Compatible with Windows 10 OS. Any other alternative software is available? Will MS SQL Server Standard latest version include this MSDE component? Please suggest.

  Friday, May 3, 2019 6:28 AM

I have to admit it, that when I first heard about this I was HIGHLY skeptical, but sure enough it actually works.

Although I have gotten SQL Server 4.21a & 6.5 running on Windows 10 (The core from 6.0 works, but it’s pre-release COM objects for the Enterprise manager don’t like Windows 10) There were two stumbling blocks I never could get around.  The first one turned out to be something trivial, which is SQL 4.21 would never listen on TCPIP.

Fixing SQL 4.21

It turns out that this actually was a simple fix.

17/09/21 19:40:24.00 server server name is ‘JADERABBIT’
17/09/21 19:40:24.00 server Recovering database ‘model’
17/09/21 19:40:24.00 server Recovery dbid 3 ckpt (45,26)
17/09/21 19:40:24.00 server Clearing temp db
17/09/21 19:40:24.03 kernel Using ‘SQLEVENT.DLL’ version ‘4.21.00’.
17/09/21 19:40:24.83 kernel Using ‘OPENDSNT.DLL’ version ‘4.21.09.02’.
17/09/21 19:40:24.83 kernel Using ‘NTWDBLIB.DLL’ version ‘4.21.00’.
17/09/21 19:40:24.83 ods Using ‘SSNMPNTW.DLL’ version ‘4.21.0.0’ to listen on ‘\.pipesqlquery’.
17/09/21 19:40:24.83 ods Using ‘SSMSSOCN.DLL’ version ‘4.21.0.0’ to listen on ‘1433’.
17/09/21 19:40:26.04 server Recovering database ‘pubs’
17/09/21 19:40:26.06 server Recovery dbid 4 ckpt (469,25)
17/09/21 19:40:26.06 server Recovering database ‘ultimate’
17/09/21 19:40:26.06 server Recovery dbid 5 ckpt (524295,12)
17/09/21 19:40:26.06 server Recovery complete.
17/09/21 19:40:26.12 server SQL Server’s default sort order is:
17/09/21 19:40:26.12 server ‘bin_cp850’ (ID = 40)
17/09/21 19:40:26.12 server on top of default character set:
17/09/21 19:40:26.12 server ‘cp850’ (ID = 2)

The DLL for TCP/IP is SSMSSOCN.DLL, and it turns out it really wants to be located in the C:WindowsSysWOW64 directory (aka the system path for libraries).  Well that’s all great now, isn’t it?

Not really.

ODBC Hell

The ODBC drivers in Windows 10 finally made a magical cut off point that they will not talk to any old and ‘vulnerable’ SQL Servers.  This means that the oldest version you can connect to is SQL Server 2000.  Even SQL 7 didn’t make the cut.  Trying to connect to a SQL 7 server, you just get:

Attempting connection
[Microsoft][ODBC SQL Server Driver]Cannot generate SSPI context

And then I saw this post, about using FreeTDS to connect to MSSQL.  So I followed their instructions, and got nowhere fast just lots of crashing.  Turns out the bloodshed environment’s included G++ just fails 100% of the time for me, with a nice crash.  So I pointed it to the TDM GCC install, and then had to link the DLL manually and… nothing.  No configuration point.  In a fit of rage, I took the exist msvc project, opened it in Visual Studio 2015, and built it, except for one issue…

odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol __vsnwprintf_s referenced in function _StringCchPrintfW

Seriously, it turns out that 2015 can’t just link to ODBC, that the libc thing that gave me SDL grief is deeply entrenched all over the place.  So in this case you need to link against legacy_stdio_definitions.lib. Fantastic.

I get my DLL, and yes, it’s a Windows 32bit ODBC driver!

And yeah, lots of failure.

A red-herring was seeing this in the trace:

net.c:741:Sending packet
0000 01 01 00 2b 00 00 00 00-53 45 4c 45 43 54 20 43 |…+…. SELECT C|
0010 6f 6e 66 69 67 2c 20 6e-56 61 6c 75 65 20 46 52 |onfig, n Value FR|
0020 4f 4d 20 4d 53 79 73 43-6f 6e 66 |OM MSysC onf|

So I was thinking that SQL 4.21 & 6.5 are just too old to have this weird table, and as mentioned over here people would just create it, to get Access to shut up, and get on with their lives.

So, I put in some SQL

CREATE TABLE MSysConf(CREATE TABLE MSysConf(Config   int NOT NULL,chValue  char(255) NULL,nValue   int NULL,Comments char(255) NULL)
GO
INSERT INTO MSysConf(Config,nValue,Comments)VALUES(101,1,’Prevent storage of the logon ID and password in linked tables.’)
GO

And yes, it creates the table, Access get’s it’s result then obviously doesn’t like it and up and dies.  Maybe I can burn more cycles on it later, or break down and ask.

***UPDATE As a follow up, check out Loading the MS SQL 6.5 drivers on Windows 10, for enabling ODBC access on newer versions of Windows.

SQL Server 2000 (Dev) on Windows 10

And then I saw this epic thread, Windows 10 & My SQL Server 2000 Personal.

I managed to install following these steps:

Extract SP4
Copy ..SP4x86othersqlredis.exe to ..originalinstallpathx86other
(this avoid mdac insall freezing)
Create this folder structure (any place):
Microsoft SQL Server80ToolsBinn
Microsoft SQL ServerMSSQLBinn
Find out sqlunirl.dll on SP4 path and copy to Binn folder above
Copy dll files on ..SP4x86setup to Microsoft SQL ServerMSSQLBinn (folder above)
Copy folder structure (created on step 3) to C:Program Files (x86)
Give full access to user logged to **Microsoft SQL Server** folder
Change install compatiblity ..originalinstallpathx86setupsetupsql.exe
XP SP2
Run as administrator

**UPDATE

Newer versions of Windows 10 don’t include the old Visual C++ runtime, and the install will fail.  Just copy the DLL’s into the syswow64 directory.

copy SP4x86systemmsvc?71.dll WindowsSysWOW64

This is tested on 17134.112 Version 1803 of Windows 10.

Could that really be it?  For some reason I had a file held in the ComputerHKEY_LOCAL_MACHINESYSTEMControlSet001ControlSession ManagerPendingFileRenameOperations registry key, preventing me from installing, but zapping the key & stub program, and I was able to follow the steps (I’m still not sure if you copy the dlls into the MSSQLBinn or ToolsBInn directories, so I copied them to both!) and yes, it worked.  I even could run the SP4 update.

And now I can use Access 2016 with this fine ancient database.

And here we are.  As always there is no larger over reaching point to this.  I did have to create a linked SQL login for myself to get ODBC to login properly but it’s somewhat simple, and honestly if that sounds bizarre to you, why are you even thinking about something like this?

For me, I’m interested in the DTS of all things.  Sure the new ones are fancier, and all that jazz, but I paid good money back in the day for old MS dev tools, and being able to use them without any virtualization, aka running on bare iron is all the more appealing.

3 ответа

Лучший ответ

takeown /f C:WindowsSysWOW64sqlunirl.dll /a
icacls C:WindowsSysWOW64sqlunirl.dll /grant *S-1-5-32-544:f
IF NOT EXIST C:WindowsSysWOW64sqlunirl.bak move C:WindowsSysWOW64sqlunirl.dll C:WindowsSysWOW64sqlunirl.bak
copy /y "%~dp0sqlunirl.dll" C:WindowsSysWOW64

"%~dp0Setup.exe" (plus your extra parameters such as SAPWD=PASSWORD)

move /y C:WindowsSysWOW64sqlunirl.dll "C:Program Files (x86)Microsoft SQL Server80ToolsBinn"
copy /y C:WindowsSysWOW64sqlunirl.dll "C:Program Files (x86)Microsoft SQL Server80COM"
copy /y C:WindowsSysWOW64sqlunirl.dll "C:Program Files (x86)Microsoft SQL ServerMssql$InstanceNameBinnMSSQL$InstanceNameBinn"
move /y C:WindowsSysWOW64sqlunirl.bak C:WindowsSysWOW64sqlunirl.dll
icacls C:WindowsSysWOW64sqlunirl.dll /remove *S-1-5-32-544
icacls C:WindowsSysWOW64sqlunirl.dll /grant *S-1-5-32-544:(GR,GE,WO)
icacls C:WindowsSysWOW64sqlunirl.dll /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

takeown /f %SystemRoot%SysWOW64sqlunirl.dll /a
icacls %SystemRoot%SysWOW64sqlunirl.dll /grant *S-1-5-32-544:f
IF NOT EXIST %SystemRoot%SysWOW64sqlunirl.bak move %SystemRoot%SysWOW64sqlunirl.dll %SystemRoot%SysWOW64sqlunirl.bak

< RUN UNINSTALLER HERE >

move /y C:WindowsSysWOW64sqlunirl.bak C:WindowsSysWOW64sqlunirl.dll
icacls %SystemRoot%SysWOW64sqlunirl.dll /remove *S-1-5-32-544
icacls %SystemRoot%SysWOW64sqlunirl.dll /grant *S-1-5-32-544:(GR,GE,WO)
icacls %SystemRoot%SysWOW64sqlunirl.dll /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

takeown /f %SystemRoot%SysWOW64sqlunirl.dll /a
icacls %SystemRoot%SysWOW64sqlunirl.dll /grant *S-1-5-32-544:f
copy %SystemRoot%SysWOW64sqlunirl.dll %SystemRoot%system32sqlunirl.dll
IF NOT EXIST %SystemRoot%SysWOW64sqlunirl.bak move %SystemRoot%SysWOW64sqlunirl.dll %SystemRoot%SysWOW64sqlunirl.bak

< RUN UNINSTALLER HERE >

move /y C:WindowsSysWOW64sqlunirl.bak C:WindowsSysWOW64sqlunirl.dll
icacls %SystemRoot%SysWOW64sqlunirl.dll /remove *S-1-5-32-544
icacls %SystemRoot%SysWOW64sqlunirl.dll /grant *S-1-5-32-544:(GR,GE,WO)
icacls %SystemRoot%SysWOW64sqlunirl.dll /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464