Sql Server and ODBC on Vista

Hey, everyone. Im currently using Microsoft sql server management studio 2008 to make my pristontale server. I've set up previous pristontale servers on different computers with no problem with the whole ODBC/Sql server aspect of it.

However, Since i believe this is my first time attempting to set a server up on vista i'm having trouble. When i go to the ODBC after i have the sql server running and i try to add the server to the ODBC i get an error that says

Connection failed:
sqlstate '01000'
SQL Server Error:10038
[Microsoft][ODBC SQL Server Driver][Shared Memory]ConnectionOpen
(PreLoginHandshake()).
Connection failed:
SQLState:'08001'
SQL Server Error:11
[Microsoft][ODBC SQL Server Driver][Shared Memory]General Network error. Check your network documentation.

When doing this i am going to "System DSN" Then to add then Sql Server
in the name field i am putting C8master
and for the server i am putting the same instance of sql server as the one i'm using in sql server manager.


Now i've searched google a bunch of times however, the solutions or answers i find i cant really follow exactly what they are saying either because the dialog boxes are different and dont say the same thing or i dont end up in the same place as the solutions. I've also tried to do it using a sql 2005 server but that did not work either.

Anyways, i'm sorry for having to ask for help but i've tried hundreds of things to get this to work and i wouldnt ask for help unless i absolutely had to. So if anyone is kind enough to help me out with this issue i would appreciate it a lot. Thanks :)

I get that all the time, and not just with Vista. It's one of the main reasons I created the database set up tool and one of the reasons I'm making a full server install CD.

Try setting ODBC up without using the "Data Sources (ODBC)" tool.

Here's how. Copy this text into Notepad, and save it with the extension ".REG" not ".TXT", and somewhere you can remember.

Code:

---

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\c8master]
"Driver"="C:\\WINNT\\system32\\SQLSRV32.dll"
"Description"="PT Server DB"
"Server"="<YourDBServerAddress>"
"Database"="AccountDB"
"LastUser"="Administrator"
"Trusted_Connection"="Yes"

[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources]
"c8master"="SQL Server"

---

Remember to change "<YourDBServerAddress>" for your database servers address.

Then double click the file, and accept to import it into your registry database.

Then you can use the "Data Sources (ODBC)" Administrative tool to check that it is there.

Good luck. :wink:

P.S. if you renamed the Administrator account, or normally run the game server from a different Admin account to the default one (usually pretty wise) then you may want to change the "LastUser" string too.

Hey! Thanks so much for the reply! i'm glad to hear its not just a problem with vista because i was getting worried that there were compatibility issues with vista with doing this.

I've done everything you've said. I made it into a .reg file and all. Now i do see the entry in the SYSTEM DSN however is there anyway to make sure that its working correctly. For example if i try to do the same thing as i did b4 and try to click next through everything should i NOT get the same error as i did before? Or should it still give me the same thing?

Also since i've been battling this problem i havnt had the chance to put in the Pristontale Databases into my Sql Server. And i know you have to set the default database to one of the ones that you copy and paste from the pristontale sql scripts. Since i have yet to create the databases for the server is that going to pose a problem for me.

Sorry for all the questions and thank you again for helping me out i'm very grateful.

Also that FULL Server CD sounds very good :) Good idea.

Thanks again for the help.

SQL should really be set up before ODBC... but, as you see, the registry install method kinda gets around that.

I'd appreciate it if you tried one of my Automated database setups for the SQL, I haven't tried them on 2008, but from the MS documentation I read they should still be good. Available either as a BATch file or a GUI set up.

Either way they are a really fast way to get it done.

The ODBC (Data Sources) Admin tool seems to have problems on fast machines, virtual machines, multi-core machines, large level-1 cache machines and x64 machines... but Microsoft basically seem to have stopped developing it after Windows 98. The new Vista Icon is nice, but you may notice from those registry keys, they are still virtualising the old ODBC.INI that used to be in the Windows folder in Win3.1.

Anyway, I figure it's something to do with poor timing code, because the moment that wizard tries to authenticate the connection it hammers the SQL server which interprets that login hammering as someone attempting a hack in to your database and denies access.

I remember the problems Windows 95 had with the early AMD K7 750Mhz processors, and the result was similar. The code runs an arbitrary number of instructions which it thinks should delay the routine long enough for the request to complete, and then processors get faster than the programmer expected and it all goes to pot.

Anyway, another point to note is that I am reliably informed by users here that the server executable doesn't need ODBC if sql.dll and clan.dll are correctly configured. However, you may find some of the VB6, ASP and PHP code for administering the server does still use ODBC connection strings. The ASP and PHP you can just re-write, but if you rely on one of the VB6 programs, you may run into issues which you would need the source code to fix if you don't have ODBC set up right.

I guess we should start looking for replacements for such tools. :wink:

However, if you write some simple code to connect using an ODBC connection string, and then close the connection and it works... ODBC is all good. I just try the server without sql.dll and clan.dll. It's not failed me yet. :wink:

Oh yea... in case you are worried about that default database, that's what the line

Code:

---

"Database"="AccountDB"

---

is about

Unfortunately i already configured my sql database before your last reply. So its already set up but if i ever need to do it again i will use your method.

Also in my previous reply i was asking that i i try to connect to my sql server using the ODBC should i NOT get that same error or should it still give me the same error? Thanks for all the help so far :)

Quote:

---

Originally Posted by mischief2013

Also in my previous reply i was asking that i i try to connect to my sql server using the ODBC should i NOT get that same error or should it still give me the same error? Thanks for all the help so far :)

---

As I say, my experience it's that "Data Sources (ODBC)" Admin tool that's the problem. Unless you are lucky, or manage to slow the computer down, I think it will always produce that error or one similar. And I think that is what you mean, at least it was in your last post.

ODBC access it's self should be fine, as that registry setting is all that Admin tool does in the end... The connection test it does when it throws the error is to ensure you don't load the registry with erronious information, but it gets "connection failed" (I think) because it tries to connect too fast on modern hardware.

Since SQL Server 2000 there is an Anti-DDoS built in that it triggers. I have had many similar messages, but the common point is that I usually (not always) get a System log message to that effect. If I keep trying, I get locked out of my own SQL server all-together. :grr:

Thanks for all the help. However now that i have all my server files etc. i'm trying to connect and getting a connection failed. I know this has been covered numerous times but i'm not really seeing anything i havnt done.

Also since i am using the Kpt test client there was no ldata.bmp in the image folder to edit. And the hotuk.ini in the client folder is in korean with weird symbols and i do not know if i have to edit that or replace it with another hotuk.ini to sucessfully connect. I Have also changed all ips to 127.0.0.1 as right now i'm just trying to play. It IS in the registry that the server ip's are 127.0.0.1 and still no luck. Any solutions?

I struggle to understand why people think that the files are the best way to see why a server and client aren't talking. For myself, I like to watch the TCP/IP stack on both machines, and log what happens. Then at least I know the signals are getting through or that the ports or protocols are different or whatever.

Likewise monitoring the file system and registry access is, for me, the quickest step to ignoring rubbish when trying to work out what files are read and in what order they are checked... then Olly will tell me what information they look for in those locations.

hotuk.ini reads 8bit per character text based commands, but each official client has a different command set. The Korean commands are the most constant across them all. But it is very easy for third parties to change the command set in executables they release.

I shall now suspend work on my new repack release, and write a guide on how to determine why a server and client aren't talking... because the greatest problem I'm having answering such queries is that there is not enough of the right kind of information to determine a single reason, or even narrow it down much. Besides, I just accidentally deleted the client I was working on to go with it. :(:

You seem pretty competent as far as these sort of problems go... so I think I can leave you with a quick diagnostic tool set, and the advise you to compare results with various clients and servers.

ProcMon Under Vista this is about the best tool to use to trace both Registry and File accesses... Under older OS, the separate FileMon and RegMon tools still work, and I still prefer to use two applications for the job when I can.

Oh it also shows network connections, but again I prefer to use TCPView on it's own.

That tells you which port each side is opening, to what IP, and when.

If the client opens the right port to the server, and the server sees it, then you need to dig deeper.

Sniphere (currently down, try to Google it, there are lots of alternate sites) is a reasonable packet sniffer that you can use to analyse the conversation between the two executables. There are several encodings, some say encryption but it's a very basic cipher that is more like a slightly different protocol.

If that is too much work for you, or it doesn't really help you to know they don't speak the same language, then you need to find another client that does speak the same language.

If the only problem is the ports, or the IPs then those are quite easy to change, and there are guides to that around here.

Thanks for your reply, I forgot to mention that im trying to run the server on the same machine i'm using for now just to get everything up and running first. Since if there's just a server or a pc that can add to my problems because it can be that the server and the other pc can not contact each other where as if they are on the same computer there's less to worry about if u know what i mean.

Unfortunately although i do have an advanced comprehension of computers this area is something i do not have much experience with and is part of the reason why im trying to configure a Pt server so i can learn. So i appreciate you being patient with me.

I will download those tools and see if i can figure out what its telling me but as of right now i dont think i'm as competent as you think i am with these type of problems. I will continue to prod around and see if i can come up with a solution and give your recommended tools a shot.

Like you said a problem with the ip is an easy fix but as of right now i dont know where i could have messed up when i put the loop back testing ip adress(127.0.0.1.) for everything.

as a side note
i admire the depth of your knowledge in this area and i really hope i can learn a great deal on this so i can become more competent in this area.

Aha! That knowledge comes from working network admin on a small site LAN of some 400 PCs with unruly users... School children to be precise. :wink: The database stuff I'm not so good at, and would usually do a lot of head scratching and consulting with collogues, but if it's to do with the network, the software or the OS that it's running on, I'm usually okay to be left alone to sort it out. :wink:

Of course PT is just for fun, but you are absolutely right that important professional skills can be learned trying to get your head around this ancient beastie.

The first part of that guide (networking problems) is up and you can check it out here. I hope it explains how I go about cutting through the rubbish in sorting out a connection... of course you can go through debugging and tracing the software for days, but if you have a network issue, checking the network packets first can save so much time IMHO.

It's like trying to figure out why your printer isn't working by fiddling around with all the buttons and dials before you check if it's plugged into the right PC. Eventually you will notice that the driver is off-line when the printer is on-line, and that that means it's not plugged into the your PC or the cable is fubared, but it would be so much quicker just to check the plugs first. :wink:

After going through your guide my client and server are not on the same port. I believe one is 10007 and the other 10009. How can i find out what clients use 10007 port?

Also like you said when i try to connect to my server i see the port really quickly and then disspears which by what you said means they are connecting but can not understand eachother because of different ports so hopefully all i have to do is get a game.exe that is a 10007 port and hopefully everything will run fine.

Also since you said you've set up a server before may i ask what server files+client and game files you used?

EDIT: I just realized that when ever i try to connect to my server through my client i see the "Users" on my server go up to 1. However i always get a connection failed.

1) The official ePT clients 3.xx.x use port 10007... I think the Brazilian official client does to.
2) Well, it's disconnecting from the server because it gets no response on the appropriate port. Sometimes even when the port is right the language (protocol) is wrong. This often happens when people change the port that the server and client operate on.
3) Mixing and matching files for servers is much of the fun for me. So I set up lots of servers with lots of different file sets and import parts from other server releases and tweak them to fit etc.

The first server I successfully set up was based on the 619 release by Sacred (xiangsho), once I was comfortable fixing bugs and tweaking settings on that I've been trying lots of them. It's more fun than playing the game for me. ^_^

Edit: Presumably the 1 goes back down to 0 a little while after you disconnect?

Yes the users goes back to 0 around 5 seconds after i disconnect. so by this do you believe this is just a port problem? Like i said i realized while using your guide that my server is 10007 and my client is 10009. Now do i just have to replace the game.exe with an EPT version or do i actually have to install the EPT version of the game to get it working?

The strange thing is all the files i used were part of the Newbies guide to making a pt server and the person that did that guide said to use KPT test client but why would he make us use that when it uses a diff port # then the fusion repack he supplied in the guide?

EDIT:Getting super frustrated here. I've used a bunch of .exe's in my KPT client hoping it would be the same port but no luck its always connection failed. I'm now even using the server_619 files to see if i can get that to run but no luck. I just want a server up im not interested about all the features etc. Do you advise that i stick with the FusionRepack and kpt game folder and client or should i go with the Server_619 and kpt game folder and client? can you please tell me what .exe works with the server_619 and what game folder you used? Ept/kpt/dpt etc...

The reason i'm saying this is because i dont know if its just me using incompatible clients and server or if this is beyond me. So if i get information that tells me this certain server definetly works with this game folder and this .exe i will know that its me and not my files so it can help me narrow down the problem.

There are a number of different servers in the pack I think... Actually, I would be tempted to download just the KPT Endless Tower 2.2 update, which is just a server executable, and use that on your server, since that uses generic 10009 KPT style communication.

The data files are pretty standard, and work from one client install to another... so a common thing to do, is install KPT official Beta, or jPT official Beta, and replace the exe with an English translation of the Korean Client executable like one of quantumfusions' or the FrogPT or PyePT released clients. (I have most joy with the Quantum 1871 / 1873 executables)

Many people then install the BMPs and TGAs (and sin files) from official ePT install over that, to get the bitmaps and UI in English as well.

well i'm using server_619 now and using frogg pt's game client using their .exe of course i changed the idata,ptreg and all that to 127.0.0.1

When i try to connect to a username that does not exist on the server i get a WRONG PASSWORD. When i actually put in one that does exists it tells me unable to connect. i've manually an account to use in my sql database and i'm quite lost as to what it could be because all my ips are 127.0.0.1

I dont know what else could be wrong. When i try to use the blood pt.exe as the client file it takes a long time and tells me connection failed. Also my server tells me 1 user when i try to connect to it. and goes back to 0 when i back out. any ideas?

The game.exe of froggPT is hexed with their IP and it means that no matter what ips you put in the ldata , reg file , it will connect to their IP .
Not all game.exe are like that . there are game.exes that takes the IP from the registry and login by that .

ahhh gotcha i didnt know the frog pt exe was like that. Damn. That means i'm back to square one. Still getting connection failed with the blood PT .exe
EDIT: I really don't know whats wrong something should have worked by now. I believe its going back to the ODBC setup since it wasnt connecting to my sql server when i tried to configure it.

Can anyone refer to some possible solutions to the error i posted in my original post? Mind you i've looked through google but dont really follow exactly what they want since i'm on vista and the dialog boxes are somewhat different.