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 ‘188.8.131.52’ to listen on ‘\\.\pipe\sql\query’.
17/09/21 19:40:24.83 ods Using ‘SSMSSOCN.DLL’ version ‘184.108.40.206’ 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:\Windows\SysWOW64 directory (aka the system path for libraries). Well that’s all great now, isn’t it?
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:
[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 __
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:
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)
INSERT INTO MSysConf(Config,nValue,Comments)VALUES(101,1,’Prevent storage of the logon ID and password in linked tables.’)
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:
Copy ..SP4\x86\other\sqlredis.exe to ..\originalinstallpath\x86\other
(this avoid mdac insall freezing)
Create this folder structure (any place):
Microsoft SQL Server\80\Tools\Binn
Microsoft SQL Server\MSSQL\Binn
Find out sqlunirl.dll on SP4 path and copy to Binn folder above
Copy dll files on ..SP4\x86\setup to Microsoft SQL Server\MSSQL\Binn (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 ..\originalinstallpath\x86\setup\setupsql.exe
Run as administrator
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 SP4\x86\system\msvc?71.dll \Windows\SysWOW64
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 Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\PendingFileRenameOperations 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 MSSQL\Binn or Tools\BInn 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.