I'm having a bit of trouble with an old website that I have inherited from someone.
It throw errors regarding a connection pool being maxed out. When it happens the website would simply then just load the HTML and nothing from the database. When it is left for a while it would then work fine, or when I would recycle the IIS application pool in Plesk.
I have done a lot of reading and research but I can't quite work it out still.
The first thing I read was to look for was any code where the database connection was not closed after it had retrieved the information. I haven't found anything like this so far.
The next thing was I found a stored procedure sp_who2 which I was led to believe would give me the open connection but I'm a little confused as to if this is what I'm actually looking at.
When running sp_who2 I get the below.
Is this an open connection? Or is it simply my connection that is currently looking at the database through SQL Server Management Studio?
This database is currently on a shared hosting platform so I don't have the access needed to run some of the other commands that I found.
Ideally I will move the website off a shared host, but I'd like to find out the reason for this before I do. What I'm hoping to find is where the code needs to be adjusted to make it work.
Is this an open connection? Or is it simply my connection that is currently looking at the database through SQL Server Management Studio?
It's both. Your connection is coming from SSMS, and it is an open connection.
There are ways to get more detailed infomration than this. You can, for example, use sys.dm_exec_connections, along with other DMV's like sys.dm_exec_sessions, and construct a query which tells you a lot of information.
But rather than write a query like that yourself, I suggest you download Adam Machanic's excellent sp_whoisactive. It's just a stored procedure you create, which contains a query to pull lots of useful infomration from the system metadata, with the ability to provide options to customise the output. This procedure is, I would be confident to say, the "default" procedure that everyone eventually uses for this kind of query. I might write my own more limited query against the DMV's from time to time, but most of the time, sp_whoisactive can give you everything you want.
One of the parameters, for example, is #show_sleeping_spids. This will show you connections even if they're not actually running any query. Which is sort of funny given that the procedure name is "who is active", but the usefulness is clear. You would want to execute this procedure like so: exec sp_whoisactive #show_sleeping_spids = 1, and perhaps add other paramters besides. It has powerful filtering options too, but if you don't typically have a lot of connections, you probably can just grab the entire output and eyeball it for relevant info.
If you can't run this because of the permissions available to you by shared hosting, then your options are severely limited. If you are only getting your own session from sp_who2, but you know other stuff is running, then you don't have view server state permission. In such cases, sp_who2 only outputs your own session (because you are allowed to see information about your own session).
Related
I use SAS EG 8.2.
And I know there is stop buttons on menu bar.
But sometimes when the requesting result of my proc sql program is little(??) bit large,
that stop buttons doesn't work.
It always goes where it hopes to go.
From time to time, it takes over 1 hour(. And now I'm waiting and asking for)...
So I hope to know how to terminate a running proc sql program at once.
There's a bunch of different possible issues here.
When you say proc sql, if you mean a job that is submitting code to a SQL database, you probably cannot force that job to quit. Your database administrator would have to do that, on the SQL database end - SAS usually cannot do anything about it.
If it's a SAS job only in PROC SQL, then often the stop button will be fine. But if not, and if it's not a local job, you may be able to use PROC IOMOPERATE to quit the job, depending on your permissions on the server. You may not be able to, as it's generally restricted to administrators, but again your SAS Admin may be able to. See Chris Hemedinger's post on the subject; he also developed an EG add-in that will allow that to work.
It is harder to control what SAS is doing when you use a front-end like Enterprise Guide to submit your SAS code instead of running SAS directly.
You could try disconnecting from the SAS Server and starting a new session.
I am completely baffled by SQL Server and OPENROWSET permissions.
Our team has an AD Group. This group is included in the DEV server's Windows Administrators local group. This same AD group has SysAdmin privilege on the local installation of SQL Server 2017.
Attempting to run the command:
SELECT *
FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0','Excel 12.0;Database=C:\Work\test.xls;HDR=YES',['sheet1$'])
works for me, but for none of my teammates.
If there is a definitive document on the security requirements for using the OPENROWSET command - I have not found it (and please - don't refer me to learn.microsoft.com - that documentation is not written in any way that I understand).
There are other issues I have found including if I change the name of the sheet in the Excel workbook - the command fails (and yes - I closed the book after making the change).
Finally - some feedback on the use of OPENROWSET - is it generally a good idea? a bad idea? pretty much neutral but be prepared for these kinds of problems?
I hope this question is specific enough to be answered - I have probably spent 20+ hours trying to figure out how to understand how this works so I can make it work and use it consistently.
Thanks!
So honestly troubleshooting security/permissions and errors with SQL Server is probably the most frustrating aspects of my job.
First few questions and thoughts about your dilemma.
Do you really want to be granting your team connected to your db
sysadmin rights? I wouldn't do that period, full-stop.
Will the data be refreshed? If yes, I suggest you ingest this data
into a sql table with a process, perhaps python, ssis, dts package,
powershell, whatever you fancy.
If the data will always be static in that one excel file, I'd suggest perhaps making it act like a linked server for (hopefully) fewer permission issues? Also, it's easier to query that way, from my memory.
In any event, this article (non msdn link) may help? I've done it this way once before and had slightly less of a difficult time, but then again it involves adding a driver (usually) to the sql server. BUT, then I did not have to allow multiple users sysadmin - and I think ANYTHING is better than that.
https://www.sqlshack.com/query-excel-data-using-sql-server-linked-servers/
Sometimes the issue is not with the user running the query, but SQL Server using the account it runs as - to get permissions on the file. This article goes over that aspect as well. I'm not sure that is your issue as you say it works for me but not for thee, but maybe read that portion of the article at least?
I have been using MS Access databases via DAO for many years, but feel that I ought to embrace newer techniques.
My main application runs on end user PCs (no server) and uses a shared database that is created and updated on-the-fly. When the application is first run it detects the absence of a database and creates a new empty one.
Any local user running the application is allowed to add or update records in this shared database. We have a couple of other shared databases, that contain templates, regional information, etc., but these are not updated directly by the application.
Updates of the application are released from time to time and each new update checks the main database version and if necessary executes code to bring the database up to the latest specification. This may involve the creation or deletion of tables and/or columns. New copies of the template databases are also included as part of the update.
Our users are not required to be computer-literate and should not need to run any sort of database management software beyond those facilities provided by the application.
It all works very nicely with DAO/Access, but I'm struggling to find how to do it with SQL Express. The databases seem to be squirrelled away in locations that are user-specific and database creation and update seems at best awkward to do by program code alone.
I came across some references "Xcopy deployment" that looks like it could be promising, but there seem to be references to "user instances" that sound suspiciously like something that's not shared. I'd appreciate advice from anyone who has done it.
It sounds to me like you haven't fully absorbed the fundamental difference between the Access Database Engine (ACE/Jet) and SQL Server:
When your users launch your Access application it connects to the Access Database Engine that has been installed on their machine. Their copy of ACE/Jet opens the shared database file (.accdb or .mdb) in the network folder. The various instances of ACE/Jet work together to manage concurrent updates, record locking, and so on. This is sometimes called a "peer-to-peer" or "shared-file" database architecture.
With an application that uses a SQL Server back-end, the copies of your application on each user's machine connect over the network to the same instance of SQL Server (that's why it's called "SQL Server"), and that instance of SQL Server manipulates the database (which is stored on its local hard drive) on behalf of all of the clients. This is called "client-server" or "server-based" database architecture.
Note that for a multi-user database you do not install SQL Server on the client machines, you only install the SQL Server Client components (OleDb and ODBC drivers). SQL Server itself is only installed in one place: the machine that will act as the SQL... Server.
re: "database creation and update seems at best awkward to do by program code alone" -- Not at all, it's just "different". Once again, you pass all of your commands to the SQL Server and it takes care of creating the actual database files. For example, once you've connected to the SQL Server if you tell it to
CREATE DATABASE NewDatabase
it will create the database files (NewDatabase.mdf and NewDatabase_log.LDF) in whatever local folder it uses to store such things, which is usually something like
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA
on the server machine.
Note that your application never accesses those files directly. In fact it almost certainly cannot do so, and indeed your application does not even care where those files reside or what they are called. Your app simply talks to the SQL Server (e.g. ServerName\SQLEXPRESS) and the server takes care of the details.
Just to update on my progress. Inspired by suggestions here and this article on code project:
http://www.codeproject.com/Articles/63147/Handling-database-connections-more-easily,
I've created a wrapper for the ADO.NET methods that looks quite similar to the DAO stuff that I am familiar with.
I have a class that I can use just like a DAO Database. It wraps ADO methods like ExecuteReader, ExecuteNonQuery, etc. with overloads that can accept a SQL parameter. This allows me to directly replace DAO Recordsets with readers, OpenRecordset with ExecuteReader and Execute with ExecuteNonQuery.
Each method obtains and releases the connection from its parent class instance. These in turn open or close the underlying connection as required depending on the transaction state, if any. So a connection is held open for method calls that are part of a transaction, but closed immediately for a single call.
This has greatly simplified the migration of my program since much of the donkey work can be done by a simple "find and replace". The remaining issues are then relatively easy to find and sort out.
Thanks, once again to Gord and Maxwell for your advice.
This answer is too long to right down... but go to Microsoft page, there they explain how to make it: http://office.microsoft.com/en-us/access-help/move-access-data-to-a-sql-server-database-by-using-the-upsizing-wizard-HA010275537.aspx
I hope this help you!!
So I've created an Access Project for one of my users so he can connect to a reporting database. The .adp project connects to the DB and he can query data to his heart's content. The problem is, no queries can be saved. Whenever he opens the project, he is presented with the following error:
"This version of Microsoft Access does not support design changes with the version of Microsoft Sql Server to which your Access project is connected. See the Microsoft Office Update Web site for the latest information and downloads. Your design changes will not be saved."
Again, this is Access 2007 and Sql Server 2005. My googling efforts - which are coming on a day when I seem to be especially stupid - keep bringing up information regarding this error for Access 2002/2003 trying to connect to Sql Server 2005, which is clearly not my problem.
I'm seeing that one can connect to Sql Server with the normal Access databases (.accdb in 2007 or some such), but I'm seeing mixed information regarding whether I want to do this or not. And since I can't get a copy of Access 2007, I can't really test this (topic for another time).
Before I do down that road, I'd like to get to the bottom of this one. Anyone have any suggestions, useful links, or useful knowledge? Or an older developer who knows the answer that is no longer needed, so I can eat him and absorb his knowledge and powers?
The account being used to connect to the DB was only a db_reader. I changed it to DBO and that fixed the problem - user can now create and save queries, and sleep at night knowing that tomorrow will bring a new day with new querying possibilities.
I'm not super crazy about this though the reporting database has been set up on a separate install/server from impotant App databases. I'm not worried about the user (or anyone on his group) blowing anything up. I'd like to understand why this is, and don't (outside of the obvious - reader is read only! I didn't expect that to extend to work in Access), and will try to do so at a later time. One of the unfortunate aspects of working at a dev shop focused on internal app development is, "well, it's working, you have other things to see to".
I am not sure if I can be of help here.
But you can have a view inside Access which connects to SQL database and use that view.
Alternatively, you can go the other way. Have a DB project with SQL Server & create a linked server to MS-Access DB.
Did you try linking to the tables through an ODBC connection?
CodeSlave, I did not. The attitude from higher up is "it's working, move on". I'm not sure the boss really wanted to go down that road anyway, but it's a moot point. I should probably try granting the account dbreader and dbwriter access and see if that accomplishes the same thing, but it being dbo isn't really a huge deal. Or rather, it's not a big enough deal that The Powers That Be want me to seek an immediate change.
I was going to try linked tables until changing the SQl Server account permissions "fixed the problem" (quotes very deliberate; it feels like one of those solutions you arrive at without a proper understanding of what it worked, which vexes me).
Is there any way to map to a network drive by using a stored procedure? I have tried:
xp_cmdshell 'net use Q: [shared_network_drive] [pwd] /user:[username]'
but I got an error saying something like
'System error 1312 has occurred.'
'A specified logon session does not exist. It may already have been terminated.'
However, when I run the same command in a cmd console in the same box as the SQL server machine, there is no problem at all. It looks like that SQL process does pass correct logon credential information. Any way to do it by SQL SP?
In an other forum someone posted a tip about how to solve the System error 1312 has occurred. problem by specifying the username including its domain like this:
net use Q: \\[host]\[folder] [pwd] /user:[host]\[username]
I tried it and it worked for me.
I spent one hour, but the problem solves: You must specify [HOST]\[username]
If you write like this: u:/username - it doesn't work
Do you have a proxy account set up for xp_cmdshell? If you are not a member of sysadmin, it requires a proxy account. The documentation for xp_cmdshell and sp_xp_cmdshell_proxy_account will explain it in detail, but try executing the following:
EXEC sp_xp_cmdshell_proxy_account 'DOMAIN\Username', 'password'
Of course, replace the user and password information with the account information on your network under which you want this to execute.
WARNING: xp_cmdshell can be a HUGE hole in security. Make sure that at the very least the proxy account that you use has very limited security. Don't use any kind of admin account and don't use an actual user's account.
Why would you even want to do this?!? Even if it is possible, you should be carefully asking yourself why you would want to do so.
My suggestion: don't. My impression is that you need to change your approach--whatever purpose that network drive mapping might serve should be pursued in a more appropriate place outside of the database engine. Once you choose that appropriate place, actually invoking the mapping will probably become trivial.
Rod, you are right. It is a big risk to do that in SQL server and not all the SQL admins would allow to open this door. What I am doing is to migrate legacy process to a scheduled SQL job so that required data will be available for another department's application to fetch data in another scheduled process.
I guess that a windows service job might be a better application to pull data out and transfer the result to the required network drive.
Actually, use Win Scheduled Tasks tool is what I need. I can create a .Net app to do the job and then add the application to the scheduled tasks.
The problem happens when using Distributed File System, no matter which operating system you're using. Instead, get the actual name of a server hosting the DFS content.