Please forgive me if this post is in the wrong place, but as your all the cleverest bunch of guys I know, advice would be appreciated.
Another user in my company wrote [and on another pc], installed the new application [written in vb.net I think - but maybe c#].
He left the company a month a go, and I have now started to get problems [or rather notice them for the first time] - the files were being logged to SQL Server on the network. Now I notice that a month ago the Network SQL Server 2008 has not been logging the data, but in fact it has been accumulating under SQL 2005 on the local machine that the software is installed on, and the temp file is over 100mb big...
I suspect that the IT department froze his account when he left, and this disrupted the SQL access and program network permissions. The Event Viewer seems to support this theory by logging red critical errors that basically say [unable to connect to SQL server etc etc].
The program runs now as a guest [It always ran as a guest]. So I cant see how freezing or deleting his account would affect things.
Do you know how I can fix this without re-installing everything?
Thanks in advance.
Jim.
here's a couple of things to check for starters:
what accounts the SQL services on the machine are running under e.g. http://sql-articles.com/articles/general/sql-server-service-accounts
which account is the application logging in as
Related
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 searched high and low for a solution to this problem to no avail.
Basically, the situation is as follows:
We are currently migrating our existing TFS server to another machine, which has been going well up until now.
Unfortunately i'm unable to complete the configuration of Report server and the likes as I get the following error:
"Failed to add SWSERVER\susan account to the TFSEXECROLE role on the Tfs_Warehouse relational database"
SWSERVER is the name of the previous machine that hosted the TFS server.
The thing is that SWSERVER\susan is an absolete account, and was actually removed as a user account on the previous machine, which I think is a major part of the problem.
From what I can gather is that TFS can still see it in the restored databases and thinks it's a viable account but seeing as the account technically doesn't exist it can't actually do anything with it.
Another part of the question is that if I go to the original (SWSERVER) and remove the SWSERVER\susan user, will that have an effect on how TFS or SQL operate especially if that account (or any other similar account) are linked to anything in either program?
I'd much appreciate any help anyone can provide.
I've hope i've explained my situation well enough but if anybody needs any more information, please don't hesitate to let me know.
You can't remove users, they will fall out of scope anyway, however that is not your problem. Your TFS instance has been moved from one server to another without following the documented procedure.
You need to follow the instruction to Move Team Foundation Server from one environment to another. Although they will be based on the more common move of Domain to Domain you can think of a non-domain joined server as having a domain of the same name as the local computer.
Now this documentation also follow as using the same hardware so you will need to mix and match between Move Team Foundation Server from one environment to another and Move Team Foundation Server from one hardware configuration to another.
While not really that hard you do need to follow all of the steps...
Just want to thank you for your reply and help. As it turns out I was flogging a dead horse with the TFS Reporting setups when I found out that the reports aren't even used currently on the existing setup.
I did however manage to figure out that if I added every user that previously existed as Windows users on the new machine and then used the TFSconfig Identities /change command to change the domain (machine name, in this case) name to that of the new server then I stopped getting the error messages and after 3-4 reinstall attempts all seems to be working the way it should.
This link was incredibly helpful:
http://msdn.microsoft.com/en-us/library/ms404883.aspx
Thanks again!
We have a windows 2003 server with crystal reports running on this, that ties to a sql db. Yesterday afternoon all reports that I was trying to run suddenly started freezing. I thought initially it was device specific and it was my pc and tried several other devices. Then one of my analysts noticed he couldn't run some standard Thursday reports which also froze .. etc.. Where does the error log for each of these reports write to so I can investigate the root cause?
Running slowly will not necessarily produce an error. The best thing for you to do in this situation is run the SQL used in your reports directly against SQL server from management studio, this way you have a whole host of performance monitoring options, you will also get a better feel of what the issue could be. Continue to troubleshoot different factors procedurally and you should find the issue.
The background to my problem is based on distributed computing. I want to have a database with some numbers in them and then a number of computers go through each row calculating another number (a little bit of an over simplification).
The problems I'm having are routed in my poor understanding of SQL servers (I think). I've got Microsoft SQL server 2012 (and 2008) installed on this machine and I've somehow managed to make a server for this task but then the problems arise.
I can't add a table to the server (I'm trying to do this in VS2010). When I expand the server and right click on tables and select add new table i get the following error:
"The server version is not supported. Only servers up to Microsoft SQL Server 2008 are supported."
That stops me making a table and from there I can't move on. I've downloaded and installed the VS2010 SP1 (and re-installed it again when it didn't fix the problem) as I found this suggested for similar issues.
Any help on this would be greatly appreciated. I've read around but nothing seems to work, people suggest using "SQL Management Studio" but I don't seem to have this installed!
Also, I haven't gotten to this step yet, but if this gets fixed any advice/links on how to access the database from a different machine (over the same local network) would be greatly appreciated!
Many thanks,
Fraser
R Harvey gave you the pointer to SSMS - that's the ideal tool to use.
As for other computers accessing your local database - the name of your computer (where MSSQL is installed) is the name of the server in your connection string.
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).