I'm trying to figure out how to get back the list of SQL servers in my Visual Studios (2012, 2015) and even in MS SQL Server management studio... I've been searching for a solution but I'm lost. Is there any way to get these servers back? Everything is working properly, I can write server manually but I'm to lazy to ask my colleagues.
The SQL Server Browser service is running. There are no Windows updates to install and the computer has been rebooted many times.
Thank you for any advice.
The SQL Server Browser service is running
Do you mean on your computer? You'll need it running on the machines you are trying to get to appear in the list.
It's a pretty standard dialog - assuming that it uses the same technology as SSMS, according to MSDN:
This dialog is populated by the SQL Server Browser service on the
server computers. There are several reasons why the name of an
instance might not appear in the list:
The SQL Server Browser service might not be running on the computer running SQL Server.
UDP port 1434 might be blocked by a firewall.
The HideInstance flag might be set.
Related
In our company we have to support a large legacy system built on Microsoft Access 2010 as frontend and SQL Server 2008 R2 as backend. The backend SQL server runs on Windows Server 2008 R2. Currently our users works on Terminal Server sessions on a Windows Server 2008 R2. A couple of days ago we started to test Windows Server 2019 and Notebooks with the latest version of Windows 10. We recognized a big performance difference while executing the same Access databases on the different environments.
For instance the creation of a report takes 27 seconds (new environment) instead of 7 seconds (old environment). The database.accdb is identical, the backend is identical (still Windows 2008 R2 Server with SQL Server 2008 R2 and SP2), only the execution environment (Windows) changed.
Does anyone of you have an idea how to explain this?
In Access 2010 the SQL server tables are linked using System-DSN data sources. On the old environment ODBC is used (Driver: SQL Server, Version: 6.01.7601.17514).
On the new environment I tested the following drivers:
ODBC Driver 11 for SQL Server (2014.120.5543.11)
ODBC Driver 17 for SQL Server (2017.173.01.01)
SQL Server (10.00.17763.01)
SQL Server Native Client 10.0 (2009.100.4000.00)
SQL Server Native Client 11.0 (2011.110.5058.00)
I created a new System-DSN using the different drivers and updated the linked tables in Access. But in any case the performance is still bad. I also tested the latest version of Access which comes with Office 2019, but again it is slow.
Sounds like your terminal sessions are getting throttled. Despite the fact that you have a SQL Server back end, Access is still doing a fair bit of thunking with the result sets, so any resource throttling differences between your Server 2008 and Server 2019 policies could be choking Access in the new server.
I think your answer is going to be found in Windows System Resource Manager. The page says it's not being maintained, but following the "Recommended Version" link leads to a generic Server 2019 page. Here's another article about how WSRM might be throttling sessions: Using WSRM to control RDS Dynamic Fair Share Scheduling.
Compare the Weighted_Remote_Sessions policy in 2008 and 2019 servers. There's either been a change to the default settings or behavior or the 2008 server policy was modified in the past to get to the current performance level.
Ok, a number of things to check.
First thing to check:
Launch the ODBC manager and check if SQL log tracing is on. I don’t know why, but I see sql logging turned on.
You NEED to be 100% sure it is turned off.
You MUST launch the ODBC manager from the command line or start menu, since the one in the control panel is for the x64 bit version, and you are using Access x32 (I assume).
So launch this version:
c:\Windows\SysWOW64\odbcad32.exe
So VERY important to launch the x32. It is assumed you are using a FILE dsn. So check these two settings:
(Make sure they are un-checked).
Next up?
Link access using the IP address of the sql server.
So, place of say:
myServer\SQLEXPRESS
Use:
10.50.10.101\SQLEXPRESS
(Of course use the IP address of sql server, not the above “example” IP).
The above things are quite easy to check.
Still no performance fix?
Then disable the fire wall on your new Terminal server (I seen this REALLY cause havoc).
And, disable windows defender on the new TS server if running.
The above tips should fix your issues.
If above don’t work, then next would be to check the priority settings for the TS server (GUI over server).
However, I am betting the above checks should restore your performance.
I have an AWS instance, on which SQL Server 2014 has been running for more than 3 years.
But a few days ago, suddenly the SQL Server stopped running.
I checked the server and tried to start SQL Server service from services, from SQL Server Configuration Manager etc. but I'm not able to start the server and got following error:
So I checked event viewer entries and I found these two errors:
I started some research work over web to overcome on this issue and I found that I can start SQL service using below command using T902:
net start MSSQL$REVCORD /T902
And SQL Server service started successfully.
But I want to make SQL Server / services back to normal as before so I can start / stop services normally.
I found on web that this cause is due to corruption in master SQL Server database, I don't have backup of master SQL Server database so I cannot restore it back.
I checked multiple threads over web and tried multiple things to overcome this issue but no luck.
So finally I decided to reinstall/recover SQL Server 2014, but I am getting another error while reinstalling:
Based on finding over web, all threads showing that I have to uninstall and reinstall SQL Server to make it normal again.
Please help! It's a live server with multiple calls continously so I cannot uninstall/reinstall SQL Server there due to possible data loss.
The first thing:
select * from sys.sysmessages where error = 5833
The message:
The affinity mask specified is greater than the number of CPUs supported or licensed on this edition of SQL Server.
Check your edition, and fix the affinity mask so that the number of CPUs satisfy the number which is supported by your edition.
You can fix it in SSMS on the Processors tab in your server properties, or using sp_configure
OK, I'm at wit's end here (not like I have many to start with, but that's a different story!). So (sigh)...
Somewhere along the line I get the distinct feeling that one or more of my database drivers have been corrupted or something, and I don't know how to fix the issue without a reinstall of Windows, which would be crazy. Here's the issue:
I am working on several web site projects, and I've been using Visual Studio 2015 Community and SQL Server 2014 Developer at home, with SQL Server Management Studio as the tool of choice for working with the databases, on a Windows 10 64-bit box. I've been developing code locally, and for the last couple weeks I haven't had need to connect to the (eventual) production SQL Server databases on my hosting provider's servers. The last time I connected (maybe two weeks ago) to them everything was fine and dandy, and I'd not had any issues before then with connectivity either.
Yesterday I needed to connect, and so I launched SSMS to sign in to the database. Instead of connecting, I got the error message about "network path not found", meaning SSMS couldn't find the database server. After several retries, I attempted to connect using Visual Studio's Server Explorer window, with the same resulting error message.
I tried to PING the server and was successful. I got a TELNET connection as well to port 1433, so the server name's correct, and I was able to resolve the name to the right IP. Still, I cannot make a DB connection to the remote databases.
I followed all of the suggestions for this basic issue, including turning off Windows Firewall, and I even turned off my cable modem's firewall, just to test whether it was something there. Still no joy.
As the ultimate step, I uninstalled SQL Server, SSMS, Visual Studio, and all of the accompanying bits, plus I deleted all of the folders for Visual Studio and SQL Server, to ensure everything I could find to delete was gone.
I opened a command prompt and ran cliconfg to make sure named that both TCP and named pipes were enabled, and they were.
I installed LinqPad after a reboot just to see if now I could connect, and still nothing.
Interestingly, I changed the connection string in the web.config file for my ASP.NET web site project on the local IIS box to point to the remote server's database, and it works.
So, now I have NO EARTHLY CLUE what's going on with my local machine that could be causing this. I've now spent almost two complete days on this. I haven't reinstalled SQL Server, SSMS or Visual Studio yet, but something's still not right that I can't get to the bottom of. Reinstalling Windows is not really an option if I can avoid it.
The question is, has anyone else run across something like this, and how can it be diagnosed or fixed?
To test connectivity try this
1. Create a blank text file in a folder
2. Rename the extensión to .udl to the text file (exmanple New textfile.udl)
3. Double click on New textfile.udl
The .udl file will show you input connection paremeters, fill them and click on Test connection. This can help you to test your drivers and SQL Server's
Interestingly, after two maddening days of pulling my hair out, I discovered that the .NET Data Provider For SQL Server was corrupted, evidently by a virus that made it past my AV software and was very stealthy, because the thing it affected was the SQL Server drivers.
The way I figured this out was to use the OLEDB data provider in Visual Studio to connect successfully to the remote database, which worked perfectly.
The fix to this was to run different AV software, which found and removed the virus, then I reinstalled SQL Server and Visual Studio, and it all works like a charm again!
I´m deploying my database to a SQL Server 2008 R2 Express instance that my software also installs. Everything works fine, but on certain target machines there are other instances of SQL Server 2008, 2005, 2000...I know that, theoretically, SQL Server instances may coexist side-by-side. But I also know that there are several conflicts between them. Internet is full of them.
My most common symptom is: server protocols are not installed with a previous installed SQL Server 2008 instance (from other vendor). In SQL Server Configuration Manager, under "SQL Server Network Configuration", the item "Protocols for 'MyInstance'" is just missing. So any client machine can connect to server.
I´d like to minimize the visits to clients house and make my application as self-deployable as possible. Is there something I can do to avoid or resolve instances conflicts? Any advice? Am I wishing for something impossible?
You probably will want to read up on what versions can live on the same server/client:
Working With Multiple Versions and Instances of SQL Server
Work with Multiple Versions and Instances of SQL Server
Both of these links have the chart regarding what side-by-side installs are supported, the second though also includes a little bit more regarding the components and those that will be upgraded to the highest release installed.
With the issue you spoke of with SSCM this can be caused by many things, most of them revolve around a corrupted installation of the management tools; or I mostly see issues with WMI calls on the client. Since most of those settings are available within the registry I would suggest looking at that side to get your instance configured and locked down.
You might also look at SQL Server Compact Edition. It is developed as an embeded database that does not require install of the full SQL Server managemnet tools. You have the same API and controlls that come with full version of SQL Server, just a "compact" install. I have interacted with one application that used it but have not done any development with it.
I have two issues both related to (I believe) my SQL Server setup. I have installed SQL Server (the full thing) from MSDN downloads of the x64 version on my Vista 64 Home Premium box. After running into multiple issues I finally got it working. This is a new box so I ported over a database that I need to work on from another server. That also worked fine. My first issue however came when I tried to open a database in SQL Server Management Studio:
"Unable to find the requested .Net Framework Data Provider. It may not be installed. (System.Data)"
The box itself isn't new and definitely has .NET installed (version 3 I believe). I found that someone posted this as a bug but as the team (SQL Server team) could not reproduce it, they removed it. I've tried installing the recommended SP3 patch to no avail. It's only when I try to open a table for viewing the data (right-click and "Open Table"). I can even execute queries and retrieve results (from inside management studio). I'll follow pretty much any suggestion to try and get this working.
My second issue is that I cannot connect to the server. I thought I could just work around it (with queries), but I did not find that it added any ODBC connections on the box, just the drivers. Management Studio can access the DB just fine, but the machine itself doesn't appear to recognize that anything is running on it, at least on the default port (1433) and no, I do not have a named instance. When trying to manually add the server to the DSN or any datasources it cannot find the SQL server (under Control Panel > Administrative Tools > Data Sources (ODBC). Under SQL Server Management Studio it appears as a registered database server (I think this is because it connects on port 1434 from what I hear? not sure). This is my primary problem, and even if I can't open the tables (the first issue) I absolutely NEED to be able to set it up so that I can connect to it. The language source I am connecting from is ColdFusion which is set up as a stand-alone server (IIS not installed, not using it right now).
As for connecting to it, make sure all the services are running. SQL Server Agent in particular.
Also, check in the SQL Server 2005 Surface Area configuration for Services and Connections. Check under "Remote Connections" to see if "local and remote" connections are on. It might be set to "local only".
CF versions 6+ do not use the OS's ODBC connections. They use JDBC over IP to connect. You need to make sure you have allowed TCP/IP connections to the DB using the SQL Server Configuration Studio. Then, use the Data Sources page in the CF Administrator page (usually localhost:port/cfide/administrator, replacing "port" with the port you're using for the CF built-in server).
Why though, would it default to this
and why would this be an issue with my
own machine (local testing)?
SQL Server 2005 is meant to be more secure by default, so not all the protocols are opened up by default.
Sql Server Agent doesn't have anything
to do with remote connections, but I
seemed to recall there being an issue
with doing discovery on the network if
the Agent wasn't started
Maybe you're thinking of the SQL Browser with named instances.
Did you try this process?
http://oakleafblog.blogspot.com/2007/03/orcas-march-ctp-on-vista-database.html