I would like to be able to programatically add a user to the report server by creating some stored procedure that accepts user_id and does inserts into ReportServer..Users and other associated tables. I am having trouble doing this (especially the column ReportServer..Users.Sid).
Has anyone been able to accomplish this in the past?
The end goal would be to have a script on my local PC that connects via osql to add users to the database so they can ad-hoc query and also add them to the report server so they can have access to the reports website. I have gotten the database access working...that was fairly easy. Having problems with report server.
Thanks!
You don't add users to RS this way. It's a seriously bad idea.
Why not just add "Everyone" into the "Browser" role? This is effectively what you are doing...
Related
I'm in a situation where I need to use a SQL server as a back end to Access 2010 database. The problem is that the server is only accessible with a SQL login. This isn't a big problem for the table part of the database - one login to the server connects all of the tables. The problem is with stored procedures that must be called. Since these are not under the ODBC umbrella, each query requires a login. I can't seem to find a way around that. Currently, I'm trying setting up pass through queries in Access, but once again - each query has to be logged in to individually. Is there a way to set up something (query setting, ODBC setting, VB structure or anything!) that will get around this problem of having to log in every time an SP is called?
I'm trying to avoid writing a whole big wrapper that handles the login and holds the password for later connections...
I need to update an MS Access app that connects to a SQL Server database. I copied the app and SQL database to my development computer, opened Access and linked the tables (100+ of them). I can see the data via Access, but all of the table relationships are lost, and the forms are giving me 3146 connection errors.
How do I straighten out the data so I can add features to the app (and eventually give the app to the client to reconnect with the original SQL Server)?
Complication: I haven't used Access in 15 years, so I'm a little rusty with it...
The relationships are NOW handled by SQL server. They have ZERO to do with Access, or a web site, or VB6, or some .net program that simply connects to SQL server. The .net program, the VB6 program, or the software you develop using MS Access has zero to do with how the relationships are setup with the given database system (in this case SQL server).
So that web site software, or .net program, or even MS Access does not change, or control the relationships you setup on SQL server. If this were the case, then which of the programs such as .net, web site, VB6, and MS access all using the SQL server at the SAME TIME would control relationships then??
So it is not possible or practical to have the client software control or set the relationships used by SQL server, since then it would be the client software controlling this, and every program that connects to SQL server could then be different!!! (and thus no enforced relationships would be possible as all programs would have differing ideas as to how the relationships are supposed to be!!!).
Any relationships settings you have in Access are thus ignored by SQL server, since it is now SQL server that is managing the database – not Access.
Access is just a developer’s tool like VB6, or say vb.net – those programs are free to connect to SQL server. Since many different programs are able to connect to SQL server, then the programs connecting are not the ones that control relationships – it all has to be done and set on SQL server.
Access will still allow you to use the relationships diagram. You can thus still draw out relationships in that window if you want, but you note how the options to “enforce” the relationships are now gray out – they can’t be used. So it still can be a documentation tool, or a means to make a cute diagram, but as such, it will not affect the operation of SQL server.
As for you errors? Well, before you attempt to open any form, you want to click on a linked table, and see if that works first. No use to try code, forms, reports if you not FIRST sure that the table links are active and working. ONLY until such time that you can click on, and open a linked table should you be concerned with trying to use forms, code, reports etc.
I would suggest you use the linked table manager, and re-link the tables. Now, I suppose you could delete the links, but I do NOT recommend that as a first try, since the table names will likely have a dbo prefix in front of them, and this will result in all your table names being changed, and that will break near everything in your application. So really try the refresh approach, since if you have lots of tables, then you have to re-name them all if you delete the links and re-link (so try to avoid my suggesting to delete the table links and recreating them – it will save a lot of work).
So first step:
Make sure the table links works. (don’t try code, don’t try forms, don’t try reports).
You need to ensure that a simple linked table works, and that you can simply open these linked tables. Skipping this step means everything else you attempt is folly and a waste of time.
So click on a linked table and see if you can then open + view that linked table data.
If not?
Then I would launch the linked table manager, and select all linked tables, and then force a re-fresh. (make sure you click on the box to [x] “Always prompt for new location” in the lower left corner of the linked table manager.
I'm a very new user to SSRS. I learned the basic things and am able to make reports using VS 2008 and BIDS. But I can't move further. I want to use the dynamic data source. My issues are:
First the user should input four credentials: a)Server name b) database name c) user id 4) password. It will help to make the connection with database and make the data source. The credential should be stored in session or cookie.
Now the user will be able to see all the reports without giving the credential because he/she has already given them.
I made a dynamic data source but the credentials are asked for every time I open a report.
Any demo project or an articles will be highly appreciated.
It sounds like SSRS alone will not accomplish what you want. SSRS will not provide a good interface for end users to create new datasources, or change existing datasources. There are some potential workarounds that get some of the functionality you desire, such as a method to change servers found at:
http://blog.softartisans.com/2011/04/19/how-to-create-a-dynamic-reporting-services-shared-data-source-using-linked-servers/
(requires the ability to use linked servers.)
But to manage the user session or cookies, you will need more than SSRS. The easiest way to get at this will be with a .NET web site to manage the credentials. It might be able to use a ReportViewer control, or other method of accessing SSRS, such as URL access, to get reporting functionality.
I am developing SQL Server Reporting Services (SSRS) reports on SQL Server 2008 R2 and using Report Manager as a method to demonstrate and test reports. I am looking for a way to allow users of the same domain to connect to the Report Manager and run reports via a browser (not SharePoint) without letting the user have too much access to the data source. I currently have each user listed as db_owner for the database that the datasets and data source are associated with. I would like to limit this access and I have tried db_datareader but this level does not allow the user to run the reports and gives the user this error: “Cannot create a connection to data source 'DBname'. (rsErrorOpeningConnection)”.
My method of adding a user to The Report Manager site: I select the ‘Security’ tab under ‘Site Settings’ and then select ‘New Role Assignment’ adding the user as a ‘System User’. I then select ‘Folder Settings’ on the toolbar and again select ‘New Role Assignment’ adding the user as a ‘Browser’. I have tried adding a user as a ‘Content Manager’ but they still have the same error when it comes to the data source.
My method of adding a user to the data source: select new login from the Security tab for the server, add domain\username to ‘Login name:’, use Windows authentication and change the default database from master to the database that is the reports data source. I then select ‘User Mapping’ and put a check next to the database that is the data source. In the ‘Database role membership for: DBname’ section I choose db_owner and public is already selected. I have included screenshots below.
My question is what ‘Database role membership’ can I use for SSRS and Report Manager that would not be as broad as db_owner and would have the best security? I have tried db_datareader but then the user cannot connect to the data source when they run the report.
I have researched this question but I have not found any details accept for adding the user as a db_owner as I described. MSDN acts as if the settings in Report Manager are all that you need to set for the user/report to have access to the data source. I have tried only using the Report Manager settings with both settings for a data source, shared and imbedded with no luck.
Thank you in advance
Typically, the data sources in SSRS will be set to use a fixed account, either a Windows account or SQL authentication. This account should be given minimal privileges to the database: db_datareader is common.
Then security to the report is controlled through Report Manager as you describe above. this avoids the need for changing security on the database itself with changes in user permissions.
But the approach you describe above should work as well. The error you see when the user has db_datareader access is surprising if your query is a standard SQL query selecting from tables. If you are using Stored Procedures, you need to grant access to those as well. Use a test user account that is set to db_datareader; see if you can connect and execute your query through SQL Server Management Studio.
Depending on your security requirements, I would use a dedicated account for database access from the reports, say "ReportReader." Develop and test your reports accessing the databases as this user, and make sure the user has minimal access, read-only and/or limited to only the tables or procedures they need to execute.
The credentials used to access the database are set in the properties of the datasource. This is one reason that Shared datasources are often used, and the reports are linked to the shared datasources:
The screenshot shows a SQL server authenticated account in use. This could just as easily be a fixed Active Directory account; check the "Use as Windows credentials when..." in that case.
I am in the process of moving several Access databases into a SQL 2008 R2 server using Access 2007 Projects as the frontends and we're running into problems when users are trying to filter data from the forms.
Example:
I have one project file setup so that the users can search customer data and I'm using a login to the server that only has "CONNECT" and "SELECT" rights so they can't change any of the data. The only form in this project has it's record source set directly to the table, no views or queries. If a user selects the "Customer#" and then presses the "Filter" button, selects "Text Filter" and enters a customer number they get an "Enter a valid value" error (same thing happens if they select a field on the form and right click and try to set a filter). If the user uses the "Advanced/Filter By Form" there's no problems.
There are no other filters set on the form or in code, no input validations, just a plan form.
Anyone have any ideas where to start on debugging this?
Thanks.
At first, you need to confirm that it is a MSSQL permission issue. To check this - try the same with MSSQL user that doesn't have any permission restrictions. Then, you can use MSSQL profiler to look at what actual MSSQL statements are being sent by Access. I beleive that it is not the simple "SELECT", but it will be some system stored procedures calls (that's how Access works with MSSQL). Look at this trace and try to understand permissions that should be added. If your Access application works on the tables level, then may be it would be easier to deny update/delete instead of granting select only - not sure that it will help, but it's just an idea what you can try.