I am a total newbie in SQL/SQL server stuff, and I am using SSRS to make a new reporting server/service and upload some .rdl files to it
I have a reporting server on a machine, which has a lot of reports and data sources uploaded to it's database.
I created a new reporting server with a fresh database on another machine, and what I want to do is to copy the old database content to the fresh one (the reports and the datasources..etc)
I have no copy of the individual reports to upload them to the new server using localhost/reports
is there's a fast solution to what i am having? please do it in detail because I never worked with SQL before.
Different ways to do this:
Report Server Databases
Use the detach/attach or backup/restore instructions here. Both of these methods require a backup of encryption keys on the existing instance, which are then restored to the new report server instance. Instructions on backup/restore of encryption keys here. Migrating the ReportServer and ReportServerTempdb databases is the easiest way to ensure all content is available on the new server.
Report Object Scripting
Reporting Services Scripter is an older (but still working with SSRS 2008R2, not sure about 2012) tool that can be used to transfer objects (folders, shared data sources, shared data sets, reports, etc) between report servers. Good choice if you want to pick and choose what is migrated.
If you are receiving an error regarding unsupported scale-out deployment, this means you are running Standard edition and need to remove the old report server entry from the database in the new location. It can be done using Reporting Services Configuration Manager, or by using rskeymgmt at command line.
Reporting Services Configuration Manager
Open Reporting Services Configuration Manager and connect to the new report server instance.
Click on Scale-out Deployment to view registered report servers.
Select the old report server instance and click the Remove Server button.
Command line and rskeymgmt
Browse to the Tools\Binn folder of your SQL Server client installation.
Run the following to list registered report servers
rskeymgmt -l -i
Using the installation ID (GUID) of the old report server, remove it
rskeymgmt -r -i
More info on scale-out deployments and rskeymgmt here.
To migrate Reporting Services, use migration manual from MSDN (https://msdn.microsoft.com/en-us/library/ms143724(v=sql.120).aspx). If you encounter "the feature: scale-out deployment is not supported in this edition of reporting services. (rsoperation notsupported)" error, go to ReportServer database and remove the old encryption key from table dbo.Keys.
Related
I am about to begin a personal project to build my skills in the .net environment. I am familiar with SQL Server Management Studio and how to create a database in it but I discovered how to make a local database in Visual Studio as well. My program is only going to require local database access as it will be used for individual inventory systems rather than connected ones. Am I ok to use the onboard tools in visual studio and create a local databasse or should I be using the SQL Server Management Studio?
When you use the Local Database item template in VS, it creates a SQL Server CE data file (SDF) and adds it to your project. When you use the Service-based Database item templete, it creates a SQL Server (Express) data file (MDF) and adds it to your project.
The advantage of using the VS tools is that the data file becomes part of your project and can therefore be easily deployed with the compiled application. As such, the database is basically part of the application.
If you choose SQL Server CE then you don't need a server installed on the user's local machine. They can install SQL Server CE or you can install it with your app if you want, but you also have the option of simply deploying a DLL with your app and it will work.
If you choose SQL Server Express then the user actually needs a SQL Server instance installed on their machine. To be honest, I'm not 100% sure whether that instance must be SQL Server Express or it can be a full SQL Server instance too. It would usually be SQL Server Express though, which you can install and even download automatically when you install your app, depending on the deployment method you choose.
If you use the VS tools to create an MDF data file then your connection string will contain the Data Source and AttachDbFilename attributes. The Data Source will generally be ".\SQLExpress", i.e. an instance named "SQLExpress" on the local machine. That instance name is not required, although it is the default for SQL Server Express, but it must be on the local machine. The MDF file gets attached at run time and detached again when you're app is done with it. It will also usually be attached to a user instance, which means that other users can't see it, even when it's attached. Note that, in later versions, the LocalDB feature of SQL Server may also be utilised.
If you create your database in Management Studio then it's not actually part of your app. It will be permanently attached to the SQL Server instance so, everyone will be able to see it and open it, assuming permissions allow. Creating the database during deployment will be an extra step in that case. You might create a backup and restore that during deployment or generate SQL scripts that get run. In this case, your connection string will contain the Initial Catalog attribute to specify the name of database to connect to, as well as the Data Source attribute. This option is required if you want multiple clients to be able to connect to the database.
In short, if you are only going to be accessing a database from the local instance of the one application then creating a database in VS is OK and probably a good idea. Whether you choose SQL Server CE or SQL Server Express may well depend on what level of functionality you need.
I have developed SSIS Package to fetch data from SharePoint Lists and importing to the SQL Server Tables. I am going to deploy this package as a Project Deployment Model.
From these SQL Tables, I have built SSRS Reporting Solution including few reports and Deployed it on my Development SharePoint Site.
But now, I have no idea how to send this solution with reports to the Client Side.
I have checked below utilities but not getting the exact idea of what I should do.
http://rsbuild.codeplex.com/
http://msdn.microsoft.com/en-us/library/ms162839%28v=sql.110%29.aspx
SQL Server version I am using is SQL Server 2012 and Data tools version is also 2012.
Please guide me here.
Thank you,
Mittal.
To deploy your reporting objects, you right-click on the project in Visual Studio then select deploy and configure the server to deploy to.
If you are trying to get an already deployed package, you can use the import wizard:
e.g.
http://msdn.microsoft.com/en-us/library/hh270294.aspx
Then the report server can be accessed by the client browser - e.g. in internet explorer, browse to to: http:
//reportserver/reports
Where "reportserver" can either be the server's ip address or reporting server name.
You can also modify these reports using the report builder tool, that will allow you to edit the rdl files on the server - e.g. when you browse to the reports, you can select edit with report builder.
If you are using sharepoint, you can use sharepoint authentication mode or you can set up access based on active directory groups at the folder level, if the client is browsing to the reports using the web browser.
I'm current using a 3rd party product, which uses an SQL Server database. I've been asked to take a copy of the database for our own backup/security purposes, but I'm having trouble.
To access the database I'm currently logging into one of my companies servers using remote desktop, where SQL Server 2005 Express is installed. Using that instance of SQL Server I then connect to the 3rd party's SQL server.
when I execute Tasks -> Back Up..., it appears to work, but the files are stored locally on the remote SQL Databases server, which my IT teams tells me is expected.
I tried using Tasks -> Generate Scripts... but the option to "Script Data" isn't available, either because it's SQL Server 2005 Express, or because the database is remote (not sure which, but probably one of those).
I've tried other things that I can't recall at the moment, and I'm out of ideas.
Can anyone suggest something that will let me get a 'local' copy of the remote databases table structure AND data?
The Generate Scripts wizard is unavailable because you are using a very old version of Management Studio Express. The 2012 version will work just fine against 2005 instances, but there is no longer an Express edition anyway, because all of the SSMS features are now available without any license.
Download the latest versions here:
https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms
I list downloads for the older versions at the bottom of this post:
https://blogs.sentryone.com/team-posts/latest-builds-management-studio/
Backups do generate locally. That is to be expected, as your team has already told you. You can generate it locally and then download it with a tool such as an FTP client. I highly recommend Redgate tools. See http://www.red-gate.com/products/dba/sql-backup/ It's a great tool and has some network backup options built in to ship your backups elsewhere. If it's a one-time thing, Redgate also has tools for that too, e.g. SQL Compare and SQL Data Compare.
The solution you pick really depends on how frequently you have to run and download backups locally and how big the DB is.
I am working on DW with SSAS cube. While development, my Cube is hosted on SQL SERVer 2008R2 on a development Server (Windows Server 2003).
Now, post to development phase I need to host the cube on test Server which would be on a remote location to which I do not have the access.
What are the possible ways I can host it on the server keeping in mind that If needed I need to re-deploy on server from BIDS Studio (when some bug arises).
What credentials I'll be needing (Will it do If I have a SQL sys rights or a windows account in that domain is a must)?
Thanks in advance!!1
In theory you shouldn't worry about it, taking into consideration of course, you have someone with access to the destination server.
You should never use BIDS to deploy your cube, it cant deal with partitions or security for example. Every deployment would overwrites these management settings of the target server.
Instead, you should use the Deployment Wizard to create your script and the you would send it to the person responsible for the deployment.
If you need more info about the deployment wizar, check my answer on this post
I had a SharePoint server, now i want to move this from one machine to another machine.
This is what i did for the migration.
I have just installed sharepoint server in my new machine and i have removed the Sharepoint_config and wss_content databased from the new server. and i have restored both the databases from the old server. Then i tried to run the Central Admin and i got Unable to connect to content database error.
Is replacing the DB is wrong. is there any other way to migrate SP server from one machine to another. I have tried my taking Farm backup and restore i had many problem with that. so i feel replacing DB would be better for me. any suggestions please?
Move SharePoint between servers is a huge effort.
Data in databases are very depends on the SharePoint install and its environments. So, I suggest just re-install the SharePoint on the new server, and then restore site collection backups to the new install.
Install SharePoint Server on the new server machine
Backup site collections from the old server, follow this guide: http://technet.microsoft.com/en-us/library/cc263441(v=office.12).aspx
Create Web Applications on the new server
Restore site collections from the prev. backups, follow this guide: http://technet.microsoft.com/en-us/library/cc262087(v=office.12).aspx
Be aware, if you have farm level customize solutions (developed by Visual Studio) or css files deployed in the LAYOUT folder, don't forget to re-deploy them on the new server.
I guess this question is too old and my answer will not help topicstarter... However, I was looking to refresh my own knowledge on this topic and I feel it will be useful to share it here.
This solution is not good for every SharePoint deployments, of course, it's just a general idea.
And I don't think it suits production environments well... but if you are brave and foolish as myself, you can do it there as well, with some additional precautions like backups and so on.
Here are prerequisites:
SharePoint was initially installed in Farm mode (not in Single Server mode)
Both old and new servers are in the same domain
You know Farm Passphrase used for initial installation
Old server is still intact and accessible from the new server
Steps to do
Skip steps 2-6 if you don't want to move databases to new location
Install SharePoint on the new server and join to existing farm. See
https://technet.microsoft.com/en-us/library/cc261752.aspx for details on joining procedure.
Ensure that the SharePoint is read-only. You can just shut down MS SQL DBEngine service if it's ok for your users.
Install MSSQL Server on the new server or other location you want. Remember, that it's not a good idea to keep SharePoint and MSSQL on the same server if it's not a demo/dev environment
Move all SharePoint databases to the new MSSQL Server. You can simply copy all DB files and attach it to the new SQL, or go full backup and restore way.
Important: Create an SQL client alias on the new server with cliconfg tool. See blogs.msdn.com/b/priyo/archive/2013/09/13/sql-alias-for-sharepoint.aspx for details.
Use your old SQL instance name as alias name. E.g. if your old server had SQL installed alongside with SharePoint on SharePoint.mydomain.com, alias name should be "SharePoint.mydomain.com"
Set Server name for alias to the new SQL location. Something like "NewServer.mydomain.com"
Ensure that you specify correct port number for SQL connection or configure network for default dynamic port. It is not necessary only if you have local SQL server on the same machine.
Create identical SQL client alias on the old server (this is needed to correctly remove old server from farm)
Remove old server from the farm. See this technet article for details
Update DNS settings or whatever you use to point users to the new server.
That's it. Hope it will help someone