How do you backup/export datasources for rapid SQL? (Could be typed rapidsql)
It is a hassle for every developer to need to setup their own datasources or if you need to move to a different machine.
If you're running one of the later versions, select the Datasource menu, then Manage Datasources. From there, you can select the individual datasource or All datasources and extract them to an XML file, allowing for easy portability.
Use the same option (Datasource > Manage Datasources) for Importing the datasources into the install on the new machine, or to share datasources between other Rapid SQL users.
Open up regedit and export the key: HKEY_CURRENT_USER\Software\Embarcadero\Registered Datasources
The settings can then be imported to any computer by simply running the saved .reg file.
Related
I'm looking for a way to duplicate an existing database, tables and data onto a different development machine. Using SQL server 2008;
I have several tools i usually use for duplicating databases or i just restore a database dump, but i cannot use any of these. I have no direct access to the database machine i can logon via SQL enterprise manager and run queries stored procedures etc. But i have no access to the file system so i'm unable to create or copy a database dump. I cannot install or connect any tools to the database as i have to logon via a remote desktop. I also only have access to copy text files on and off the network.
I would like to run a script to generate a script to create the tables, views stored procedures etc and a script to populate the tables with some data.
I need to create a test environment so i can run tests and develop new features without affecting the live DB.
Assuming you have access to the database via SSMS, this is the approach I would take, though it could be time consuming:
Right click on the Database
Hover 'Tasks'
Hover 'Generate Scripts' and complete the process, it's self explanatory.
And from there it will generate a script for the Database architecture. This is the quick portion.
Next download Visual Studio and get the Integration Services add on. Using SSIS packages you'll be able to select all data from each source table/database and then insert the data into the destination table/database. Hope this helps you get on the right path.
I have a rather large database I am working with and I am about ready to break something. To prevent this affecting live data, how would I use the live database to setup a local database? Not sure if this is even possible but I do know you can setup a local db.
You can create a SQL Server Data Tools database project type, then right click the project file and do an "Import..." to import the database to your local machine. Then you can deploy the local DB and it will be available in the SQL Server Object Explorer locally. This way you don't have to install SQL server on your machine - everything's in Visual Studio. Hopefully you are developing with a small set of data locally.
Answer
Use Visual Studio's Data Comparison tool to synchronize data to your target database from your source after you've created the database (schema only, no data) in your local database server.
Steps
From the Visual Studio's SQL Server Object Explorer:
A. Create the local database
Add two SQL Server Objects: One that connects to your production server and one that connects to a local (development/testing) server. If you need help setting up a local server then take a look at SQL Server LocalDB
Add a New database in your local server to receive the data (don't over think this step).
B. Migrate the Schema
Right-click the source (production) database and click Schema Compare...
From the SQlSchemaCompare tab that opens, use the Select Target dropdown to select your local database as the target.
From the SQlSchemaCompare tab, click Compare.
Uncheck everything in the comparison results except for the Tables, Views, and Procedures (unless you know what you're doing) then click Update.
C. Migrate the Data
Right-click the source (production) database and click Data Comparison...
Follow through the prompts to select the Tables to migrate then click Finish.
From the SQlDataCompare tab that opens, review the comparison results (it should make sense to you) then click Update Target
That's it! Either your local database is ready with data, or you confused your target/source and wiped out all of your data in production. Either way, you're done for the day.
(distinction, I'm talking about distributing a report--not deploying a report to a report server)
To our product we've recently added support for it so it can dump various stats to a database (mssql server). Since then, I've made reports (where the datasource is my own sql server). But if I want to get these reports into the hands of customers (pointing to their own database, obviously) so they don't need to make their own (or if they don't want/can't make their own) is there a good way to do this?
I'd rather not have to give instructions on how to use the report creator and have them copy/paste what I've done nor have them open it and change the datasource. I'm completely new to using SSRS and don't know any of its intricacies. I know I can query the database to see what reports are available, is there a way to just add an entire report to the database via code (c# or java)?
Assuming that they have SSRS installed and configured, and assuming that their DB (tables, SPs etc.) match your report - one of the way this could be done is:
When creating your report use a shared datasource (don't use one embedded into report)
Ask a customer to create shared data source in their SSRS instance under the same name, but pointing to their DB
Profit! That's it, all you have to to is to give them the RDL file, they will upload it to their SSRS. It will use shared datasource they provided to pull data from their DB
TThanks, for reading, I'll try to explain my issue in a detailed format as the question I'm asking is a bit high-level for my experience-level.
I'm using VS2005 and SQL Server 2005 with Reporting Services. All of my reports are built in VS2005. The reports are deployed to folders named "Amort" or :Amort_Test" on the Report server depending on the configuration I choose when I deply (Production delpoys to "Amort", Test deploys to "Amort_Test").
In Reporting Services Report manager, I have a data source setup call AMORT (and that is the datasource in my VS2005 reports). The datasource is of type Microsfot SQL Server and the connection string is "Data Source=uslibsql310;Initial Catalog=AMORT_P".
What I'd like to do is have the ability for the reports in the "Amort" folder point to a database called AMORT_P on my server (uslibsql310) while the reports in the folder "Amort_Test" point to the database called AMORT_T on the same server (uslibsql310). Obviously my current configuration, where reports in both folders point to the same datasource, says that reports point to the AMORT datasource which currently points to AMORT_P.
My initial thought was that I could create a new datasources, call it AMORT_Test and have its connection string be ""Data Source=uslibsql310;Initial Catalog=AMORT_P". However, every time I'd deploy my reports, I'd have to change the datasource in VS2005 to read AMORT_Test instead of AMort and then deply, which would be abit of a hassle.
Can anyone think of a more user-friendly solution to this? I'm one who normally finds the quickest solution and goes with it, but in this case I think there must be a way to set this up so that the reports in one folder know to pick one DB and the reports in another folder know to pick a different DB, but my current setup doesn't allow that. I'm not sure where to start in trying to figure this out as I'm a bit of an RS novice.
You're almost there, I think. If I understood correctly, here's your current setup:
One shared datasource
Reports all use that shared datasource for datasets
Two configurations: test and production, each with its own target folder
What you can do now is set OverwriteDataSources to False. Manual labor is required to set the connection string for deployed reports only:
For initial deployment of reports
When you want/choose to change the connection for deployed reports
This manual labor can be either:
Changing the connection string, temporarily enable OverwriteDataSources, and re-deploy
Going to the report manager web frontend to change the connection string
However, your default setup would be to deploy reports to both configurations, without having to worry about connecting test reports to production databases and vice versa.
I have a solution that contains multiple reporting projects (one per target deployment folder - I think this is the only way to achieve this effect, at least until I abandon Visual Studio for report deployment).
I want to specify my data source information "once and only once" for all these reports.
So far, I have created a separate reporting project that contains my shared data source. If I deploy things to a reporting server in the right order and offer sufficient prayers to appropriate gods, the reports seem to link up to the shared data source there and run (at least via the Report Manager in IE).
When I am developing a report, though, I can no longer "Preview" to try it out locally - I now must deploy it to a report server to try running it. This is a hassle.
Is my only recourse to add a whole bunch of copies of a data source (pointing at my development database), one in each project, set those not to deploy off my machine, and (probably) exclude them from source control?
A technique (dirty trick?) I am playing with now is to copy my data source (.rds) into each project, close Visual Studio, then in the underlying files/folders:
Delete the copied .rds from my report projects (leaving only the one copy in my Data Sources project)
In each report project's project file (Foo.rptproj), change the text of the Project.DataSources.ProjectItem.FullPath element from My Shared Data Source.rds to ..\Data Sources\My Shared Data Source.rds
This way all reporting projects reference the same underlying file on the filesystem, so they share a single data source definition, but each project also kind of has a "local" shared data source, so Visual Studio is kept happy.
Regarding source control: there is still only one copy of the .rds checked in, so we're not polluting the code base with lots of icky duplicates; the changes to the .rptproj files can be checked in, so we're not forcing developers into unnatural source-control gymnastics (selective partial commits etc.) to maintain a sane master copy.
Each reporting project will try to deploy this data source, though I've forbidden the overwriting of existing data sources on the server, so it's not too big a deal . . . and I suppose if I intended to overwrite the server's data source definition, it wouldn't really matter whether I overwrote it once or ten times with the same .rds.
Disclaimer: this is still an experiment. I don't have experience using this technique in practice yet, so I can't go so far as to actually recommend it.
Woody,
What we have tended to do is:
On the server have a folder called "DataSources", which is hidden from the users. In there will be all of the data sources.
For each reporting project in VS there will be a folder, also called "DataSources", but this time it will only contain the data source for this report.
As long as the folder structure is the same (i.e. report and data source have the same corresponding folder level on server and in VS) this seems to work for us.