I have to admit it, that when I first heard about this I was HIGHLY skeptical, but sure enough it actually works.
Đang xem: Sql server 2000 retired technical documentation
Enterprise Manager looking at the infamous PUBS database
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.
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
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!
FreeTDS Access failure
And yeah, lots of failure.
A red-herring was seeing this in the trace:
net.c:741:Sending packet0000 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)GOINSERT 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.
Xem thêm: Trường Đh Thương Mại Công Bố Điểm Chuẩn Đại Học Thương Mại Năm 2020
***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 SP4Copy ..SP4x86othersqlredis.exe to ..originalinstallpathx86other(this avoid mdac insall freezing)Create this folder structure (any place):Microsoft SQL Server80ToolsBinnMicrosoft SQL ServerMSSQLBinnFind out sqlunirl.dll on SP4 path and copy to Binn folder aboveCopy 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** folderChange install compatiblity ..originalinstallpathx86setupsetupsql.exeXP SP2Run 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.
Access 2016 with SQL 2000 via ODBC
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.
Xem thêm: Nằm Mơ Thấy Người Chết Đi Sống Lại Là Điềm Gì? Đánh Lô Đề Số Gì?
This entry was posted in microsoft, Microsoft Office, microsoft windows, SQL Server, Windows 10 by neozeed. Bookmark the permalink.