I'm writing a client and TWO servers in Delphi XE8.
One server is a normal program with forms, the second is a windows service.
Both expose the same three functions: a simple "ping", a file transfer, and a query on a MS SQL 2008 R2 database.
When I use client and the "program" server, all works well, I can write a query on the client, send the query to the server, and receive data.
When I use client and the "service" server, some parts work, but if I can write a query on the client, send the query to the server, the server receives the query, but it can't access the database.
I work on a VMWare virtual machine Win7 32 bit, with Delphi XE8 and TMS Sparkle as transport system, and DBExpress ad DB access.
I have turned off antivirus and firewall.
SQL Server is well configured, protocols, ports, browser is running.
The service runs under LOCAL SYSTEM (with every other user the service can't start, I don't understand why).
I think TMS creates a thread every time it receives a request, and my code is inside this thread.
Inside the thread I create a form, a TSQLConnection with owner the form, and a TSQLQuery, and try to open the connection.
In my log I find "SQL Error Code: 53": server not found or ... (there is nothing after "or").
I suppose it could be a permission problem, but i don't know for sure.
Some ideas?
Solved: I made a mistake in the SQL password ...
Related
I have been trying to figure this out for days now... I have this old application that I have not had to mess with in years and this old windows 2000 (32bit) machine went out on me. So I ended up replacing that machine with a new Windows 7 (64bit) machine.
Everything seems to be working just fine with the exception of one thing. When I try to connect to the database with the app it keeps prompting me for a password as if it's not able to connect or see the server is a SQL Server in the first place!
I have tested the connection with the ODBC Data Source Administrator and that worked perfectly "TESTS COMPLETED SUCCESSFULLY!". But when I try to connect using my app it just times out and asks for me to enter the user/pass again. :/
I had another old machine (windows 2000 32bit) up and running and it was accessing the db just fine so I know the server is setup right with open ports and no firewall etc..
I just can't seem to find a reason this client will not connect! Any ideas?
Update #1:
It seems that when turning on logging auditing in the SQL Server Management Studio I was able to see the following two log entries (in the following order)...
TEST #1
Login succeeded for user 'pubclient'. Connection made using SQL
Server authentication.
Login failed for user 'pubclient'. Reason:
Failed to open the explicitly specified database.
So when I try this on the local client machine with the temp install of SQL Server 2008 r2 it works perfectly fine. Same exact settings just a different host in the settings ini file used!
TEST #2
Login succeeded for user 'pubclient'. Connection made using SQL Server
authentication.
Starting up database 'iri'.
Login succeeded for user 'pubclient'. Connection made using SQL Server
authentication.
I don't have to specify a database on the local machine (client->client), so why do I when trying to connect from client->server?
UPDATE #2
So from what I can tell at this point is if I use a bogus host (one that can not be pinged) this application will ask me for a user/pass (because it can not make a connection to anything). If I use a host that does respond to a ping it seems to be happy and proceed. By proceed I mean it will connect to the correct remote server (as shown in UPDATE #1 on TEST #2) but before it does the second login attempt (Login succeeded for user 'pubclient'. Connection made using SQL Server authentication.) it decides to try and connect to the LOCAL SQL server I set up as a test on the client machine!!! I do not have the client host listed ANYWHERE in the settings (the client machine name was just made up so it's not hard coded). For some reason now that I have upgraded the client PC to Windows 7 64bit (from Windows 2000 32bit) it wants to continue trying to connect to the local machine instead of the remote host like it does initially!! WHAT THE HECK! I have no clue why it wants to connect to the localhost instead but this does NOT happen on Windows 2000...
I would suggest trying a "more exact" connection-string.
https://www.connectionstrings.com/sqlconnection/connect-via-an-ip-address/
Data Source=190.190.200.100,1433;Network Library=DBMSSOCN;
Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;
or
Data Source=190.190.200.100,1433;Network Library=DBMSSOCN;
Initial Catalog=myDataBase;Trusted_Connection=True;
This connection string has an IP address and Port, specifies the Network Library (tcp/ip) (Do a search for dbmssocn and you'll find the others, but dbmssocn is the first one to try). The first one above is for sql server authentication...the second one is for integrated-security.
I mention this because I had issues with a client that would not work with named-pipes, but worked with tcp.
It's not a great chance this is it, but its worth a shot.
I see you are using ODBC. You need to make sure you set up a 32 bit ODBC. To do that you must use ODBCAD32.exe in the wow64 directory. The default ODBC admin on the start menu goes to the 64 bit, and your app (being 32 bit) will not see this. So it might be a crappy app hiding the fact that it can't find a DSN with a login error message.
Take a look at this https://superuser.com/questions/419832/how-can-i-open-the-32-bit-odbc-data-source-administrator-in-windows-7-64-bit and please confirm that your app is running in 32 bit mode (has a star next to it in task manager)
We recently moved a database from MS SQL Server 2000 to MS SQL Server 2008. Everything works as expected with our main .NET client application but we are having problems with a MS Access 2003 application which connects via ODBC. A System DSN is used to make the connection.
When the database was running on SQL Server 2000 the Access application would request a user name and password once when the program was first started. Now, with the database running on SQL Server 2008 a user name and password dialog is requested every time a different table is accessed I believe.
This behavior occurs when using either the user account we have used for years and it also occurs if I use the database system admin account ( I know this is bad practice, it was just a test. )
What do I need to reconfigure to return to the previous, desirable behavior where the user is only authenticated a single time?
You could look at using a "DSN-Less" connection to MS SQL, microsoft provide instructions here: http://support.microsoft.com/kb/892490
The relevant connection string can be found here: http://www.connectionstrings.com/sql-server-2008#p3
All this aside, JMK's question is important, the method above is for if you are having linked tables to the server present in your Access database, however when working with dedicated database server's I always advise using "ADO" connections rather than "DAO" as this will avail better performance (especially if you are running queries)
If it is just queries you need to run then consider either the ADO method or take a look at the "Pass through" queries option, this like ADO will have the server doing the work rather than the local machine and the performance will be greatly improved.
We've been experiencing a strange issue with SQL 2008 R2 (10.50.1600) installed as a named instance. In order for any external clients to connect, we have a certain procedure we have to follow, but should not have to. Now I did in fact open the TCP/IP and Named Pipes protocols on the SQL server and restarted it, this isn't the problem. We're on an Active Directory Domain (running from Server 2003). The problem exists no matter what OS the server or client is (XP, 2003, 2008, Vista, 7, 64bit, 32bit, etc.). The problem also persists from anything which can connect, for example, SQL Management Studio, ADO (from our applications), etc.
The problem is that before any client can connect to this server, each client machine must first connect to this server through ODBC (and we don't use ODBC). Any attempt to connect to a 10.5 SQL server before doing this results in "Server does not exist or access denied". But once we can connect in the ODBC (through Named Pipes), then everything else starts to work. The same issue occurs both when using the Computer Name and IP Address. In fact, if we want to connect with computer name \ instance name, then we have to do so first in the ODBC, and then if we want to connect via the IP address \ instance name, then we have to do the same also for that.
We've been having to do this on every single client computer. Again, once the ODBC is able to connect to this SQL server through Named Pipes, then all future attempts from that client work.
What could be causing this to occur? How to avoid it? I should not have to do this "ODBC Trick" as we've been calling it. I've never had this issue on any other version of SQL.
The issue might be related to the SQL Browser service. Each sql instance will have a different port number - try connecting from the client as IP Address,Port (e.g. 123.123.123.1,1433) - this will exclude DNS and Browser from the equation
Edit: now knowing that it is browser related, try see why clients can't access SQL Browser (usually Port 1434). Service not started? Possibly firewall blocking?
Microsoft have tied down everything security wise now by default, so any new configuration now generally requires quite a bit of detailed security planning, policy configuration, permissions etc. Welcome to the age of non-trust ;)
You could easily test your connection by creating a simple file. Follow the steps here at "How to test an SQL Server connection": http://teusje.wordpress.com/2012/02/21/how-to-test-an-sql-server-connection/
I setup the my WCF service on server machine.
The server OS is Windows 2008 with SQL Server 2008 Express.
I am trying to access to my SQL Server (mdf) file to read data using LINQ to SQL.
I see that the DataContext is OK - but when I try to get information that in one of the table I get an exception
Failed to generate a user instance of
SQL Server due to failure in
retrieving the user's local
application data path. Please make
sure the user has a local user profile
on the computer. The connection will
be closed.
I don't know what i need to define or change in the IIS 7.5 that I'm using in the server side.
Thanks for any help.
Update: the connection to the database file is fine - but getting information from table is thru an exception. The connection string is:
Data Source=.;AttachDbFilename=|DataDirectory|\ServiceData.mdf;
Integrated Security=SSPI;User Instance=True
If you already have a server, why don't you just attach the MDF to the SQL Server (Express) running, and then use it like a normal database on your server?
After you do this, use a connection string like:
server=Server\SQLExpress;Database=YourDatabaseName;Integrated Security=SSPI
I never quite liked the AttachDbFileName= and User Instance approach - seems like a (unreliable) hack to me, which really doesn't make sense if you're running on a server machine.
The reason that you are getting this error message is because your code is in the security context of a user that has never logged on to the server. The user therefore does not have a profile and you therefore get an error when the code attempts to write to a non-existant profile.
You could use marc_s's approach or you could run as a user that has a profile.
Our MS Access application with linked tables to SQL Server 2005 is slow when using Windows Authentication from Windows XP clients.
We've been running it successfully using SQL Server authentication, but now we want to move to Windows Authentication for better security control.
Setup:
Database server: Windows 2003 Server, SQL Server 2005 SP2
Client: Windows XP SP3, SQL Server ODBC driver v2000.85.1132.00
MS Access application: MS Access 2003
Connection string:
DRIVER=SQL Server;SERVER=[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Only the TCP/IP network protocol is enabled on the server.
The slowness does not happen in these situations:
App on DB server, SQL Server Authentication
App on DB server, Windows Authentication
App on Windows XP client, SQL Server Authentication
SQL Server Management Studio on client, Windows Authentication - I did a small test with running 15 queries in SQL MS. This went fast and did not cause any logon/logoff events in the Security event log on the server.
I've analyzed the slowness using SQL Server Profiler and the event log on the server and it seems to come down to this:
The application runs a query
A new connection to SQL Server is opened (visible in SQL Server Profiler)
The identity of the user is verified (visible in the Security event log on the server, a logon/logoff event happens). This takes several hundreds of milliseconds.
The query runs on SQL Server
Results are returned to Access
This happens for every query. Some of the forms run +- 10 queries when showing a new record (updating sub forms, loading values for combo's etc). This results in very slow performance.
Of course setting up a new connection to SQL Server for every query isn't necessary, and reusing connections might solve the issue. I've been looking around for information on how to make sure Access/ODBC does proper connection pooling. I found these MS KB articles:
Frequently Asked Questions About ODBC Connection Pooling
How to Enable Connection Pooling in an ODBC Application
I've tried calling the SQLSetEnvAttr function from the main form of the Access application, but this didn't improve results.
Any help is greatly appreciated.
The first question I have is: are you running a domain controller? This may sound like a crazy question, but I just want to make sure. Although is less and less common, I've seen organizations run Windows networks with workgroups and "pass-through" authentication. The symptoms you describe are the same as would be observed on a network that is set up in this fashion.
Assuming you do have a proper domain set up, you must have a problem somewhere in the Named Pipes network stack. Named Pipes is the default protocol if you're using Windows authentication. It's not a bad idea to get to the bottom of this if you have the time, but if you just want to fix your performance problem, then I would force the TCP/IP protocol in your connection string:
DRIVER=SQL Server;SERVER=tcp:[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Note the addition of the tcp: prefix. I got this syntax from Jon Galloway's blog. TCP/IP is the default protocol for SQL Server Authentication. You can also make the protocol switch by disabling Named Pipes support on the server, but this is more of a hassle and could cause other unanticipated problems.
Check Microsoft SQL Server Native Client
at http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang=en