Need to migrate data from Sql tables to SharePoint 2013 lists. The database size is approximately 80 GB and need to move the contents from Sql tables to SharePoint lists with same schema.
Just want to know if there is any tool available for this. Or do we need to create an application (probably in .net) to fetch data from Sql and write back to SharePoint lists.
Any suggestions.
Try to see this article:
How to: Create an External Content Type Based on a SQL Server Table
In addition, see CodePlex, if you will use SSIS to perform the exportSharePoint List Source and Destination in the Microsoft SQL Server Community Samples: Integration Services project on CodePlex.
Using current toolchain you may consider using this path:
Open Excel
Add a data connection to your SQL Server
Import all data you want to have as a SharePoint list - you got a sheet now
Save as *.xlsx file
Go to SharePoint 365, select "New List"
Choose "Import from Excel" in the "New" dialog
There appears a sheet preview where you can adjust column types (most likely needed)
Click "Next", give the list a name (you may need to remove the silly Guid attached to the generated name, apart from this the name is the table name)
Click "Create"
Done
For a single table with roughly 800 records it takes 2 mins approx.
Related
I'm migrating an SSRS installation from SQL Server 2005 to 2016. Last time I did this was I migrated it from SQL Server 2000 to 2005 and this is still the same ReportingServices databases.
I restored it on another server, set up a SSRS instance and going through all the active reports to check them.
This time I'm also deleting all data sources that are in folders or used by single reports and pointing reports to shared data sources.
My problem is that most of the time this is run by developers who develop, upload and set permissions for folders and reports and I've found that I cannot delete some data sources. I've pointed the reports to shared data sources but I want to get rid of these unused data sources.
I've added myself to the top level and lower level folder content manager role but still cannot do it
My worry is that developers will overwrite these reports with changes and upload them with a local data source or create new data sources again. In a DR situation I don't want change dozens of data sources.
If you can add yourself as an Administrator role, you should be able to do whatever you want. Failing that, I can guarantee this will work:
You can go to your SSRS config tool to confirm the ReportServer Database location but it is probably located on your SQL Server in the ReportServer$INSTANCENAME database.
In there is a dbo.DataSource table which contains all of the Data Sources. You can look for the name of the Data Source you want to remove and drop that row from the table. Be careful that this also contains all Paginated embedded Data Sources so make sure you have the right one identified before you drop it.
I am looking at a sql server database for a tfs 2010 install and I am trying to find bugs/files logged by date.
Is this information contained in the database?
I see other information such as a view named WorkItemChanges which shows all the stories that have been changed by date.
* Directly querying the collection database is unsupported *
The Tfs{YourProjectCollection} database contains all work items for a specific project collection. They live in the different Work Item tables, since a bug is a specific type of work item.
If your TFS environment is configured for reporting using Report Server, then you can use the Analysis cube or the TFSWarehouse databases to query this kind of information. For work items, a limited set of fields is stored and the same goes for files in source control. You should at least be able to find out which have changed. The following doc describes the warehouse structure: Creating, Customizing and Managing reports for Visual Studio ALM. A quick way to get started is from the Excel Powerpivot reports which are installed to your team project by default if your TFS instance is connected to a Sharepoint server with teh appropriate features enabled.
* You have a number of alternatives *
I suppose that your Visual Studio is currently working, if that's the case then there is no need to use a SQL query to get to the information you're after.
To query all bugs (or other work item types) that have changed between two dates, create a work item query (in Visual Studio) that looks like this:
You can import these into Excel for easy manipulation or further aggregation. And you can even quickly create a Report from that. More information can be found in the Bulk Add or Modify work items in Excel.
To query all files changed between a specific date range, is a little harder. You can quickly get all changesets between two dates using the commandline using tf history $/Project /collection:yourprojectcollectionUri /recursive /version"D2012-10-10~D2013-10-10" this will popup window with all changesets between these dates. You can specify /noprompt /format:detailed to dump all details to the command prompt window.
Alternatively, you can do a folder diff between two dates. This can be done from the UI in the Source Control Explorer. Or from the commandline using tf diff or tf folderdiff
I have a bunch of old reports in MS Access that I want to just move over to SQL Server.
Is this possible to do? What steps need to be taken?
Identify a Report to convert
Open the Report in MS Access in Design mode
Get an old copy of the report or run the report out of MS Access (as the basis of making a SSRS report)
Open the Report Properties and find the Record Source the Report is using: qry_Intermediary_Summary
Goto the Queries tab and right click the Query and choose Design View:
Right click and choose SQL View
Copy the MS Access SQL into SQL Management Studio
Edit the MS Access SQL so it is SQL Server compliant:
Escaped column names that are reserved SQL Keywords (eg GROUP)
Replace double quotes with single quotes
Make sure Table/Views exist
Remove Dollar signs
Convert Trim(...) to LTrim(RTrim(...)))
etc
When a Query uses nested queries we need to convert them to Stored Procedures and load the data in Temporary tables. eg
This SQL uses 3 nested queries:
qryTopStocks
qryTopStocksBuys
qryTopStocksSells
We cannot make the queries Functions that return Tables because Functions dont support ORDER BY
We cannot turn the queries into Views because Views do not accept parameters
So we have to convert the queries into Stored Procedures:
Then in our DataSets we execute the Stored Procs into Temporary tables that we can join:
Once you have the Query and it is returning the exact results as MS Access (view the old report to check), then we can create a new report.
I have used the MS Access to SSRS conversion tool. It managed to get the MS Access report designs but couldn't extract data. These SSRS2005 version reports are in directory AAA. Copy the Report you are converting from the AAA folder into the BBB project folder.
Import the old SSRS2005 report into BIDS/SSRS2016:
Select all the controls and copy them onto a new SSRS2016 report. Then delete the SSRS2005 report from the project. You only need it to copy the controls retaining the design, fonts and styles.
In BIDS map all the controls to their field in the DataSet.
UPDATE: I just found this, its quite helpful: https://www.databasejournal.com/features/msaccess/article.php/3705151/Converting-Access-Queries-to-SQL-Server.htm
And this is a really good explanation of MS Access queries vs SQL Server queries for linked dBs
https://www.mssqltips.com/sqlservertip/1482/microsoft-access-pass-through-queries-to-sql-server/
I would like to copy a table from one database to another. I know you can easily do the following if the databases are on the same SQL Server.
SELECT * INTO NewTable FROM existingdb.dbo.existingtable;
Is there any easy way to do this if the databases are on two different SQL Servers, without having to loop through every record in the original table and insert it into the new table?
Also, this needs to be done in code, outside of SQL Server Management Studio.
Yes. add a linked server entry, and use select into using the four part db object naming convention.
Example:
SELECT * INTO targetTable
FROM [sourceserver].[sourcedatabase].[dbo].[sourceTable]
If it’s only copying tables then linked servers will work fine or creating scripts but if secondary table already contains some data then I’d suggest using some third party comparison tool.
I’m using Apex Diff but there are also a lot of other tools out there such as those from Red Gate or Dev Art...
Third party tools are not necessary of course and you can do everything natively it’s just more convenient. Even if you’re on a tight budget you can use these in trial mode to get things done….
Here is a good thread on similar topic with a lot more examples on how to do this in pure sql.
SQL Server(2012) provides another way to generate script for the SQL Server databases with its objects and data. This script can be used to copy the tables’ schema and data from the source database to the destination one in our case.
Using the SQL Server Management Studio, right-click on the source database from the object explorer, then from Tasks choose Generate Scripts.
In the Choose objects window, choose Select Specific Database Objects to specify the tables that you will generate script for, then choose the tables by ticking beside each one of it. Click Next.
In the Set Scripting Options window, specify the path where you will save the generated script file, and click Advanced.
From the appeared Advanced Scripting Options window, specify Schema and Data as Types of Data to Script. You can decide from here if you want to script the indexes and keys in your tables. Click OK.
Getting back to the Advanced Scripting Options window, click Next.
Review the Summary window and click Next.
You can monitor the progress from the Save or Publish Scripts window. If there is no error click Finish and you will find the script file in the specified path.
SQL Scripting method is useful to generate one single script for the tables’ schema and data, including the indexes and keys. But again this method doesn’t generate the tables’ creation script in the correct order if there are relations between the tables.
Microsoft SQL Server Database Publishing Wizard will generate all the necessary insert statements, and optionally schema information as well if you need that:
http://www.microsoft.com/downloads/details.aspx?familyid=56E5B1C5-BF17-42E0-A410-371A838E570A
Generate the scripts?
Generate a script to create the table then generate a script to insert the data.
check-out SP_ Genereate_Inserts for generating the data insert script.
Create the database, with Script Database as... CREATE To
Within SSMS on the source server, use the export wizard with the destination server database as the destination.
Source instance > YourDatabase > Tasks > Export data
Data Soure = SQL Server Native Client
Validate/enter Server & Database
Destination = SQL Server Native Client
Validate/enter Server & Database
Follow through wizard
I need to upsize a split Access database, i.e., one that's currently split between tow mdb files, a front-end and back-end. I see many webpages that in essence say, "run the Upsizing Wizard." My first, very basic question:
Should I be running this wizard in my front-end mdb or my back-end mdb?
I assume I don't want to link main mdb -> backend mdb -> sql server. Should I run the wizard on the backend mdb, and then in the frontend mdb change the linked tables to point to sql server rather than to the backend mdb? If so, how is this done? When I right-click and go into the Linked Table Manager for a table in the frontend (linked to the backend md), it only seems to let me choose a new mdb file.
I would agree with your first guess: you will want to run the wizard on the back-end mdb.
Once that's in SQL Server, also as you guessed, you'll want to link the front end to work with the SQL Server data. One way to do this is to set up an ODBC data source for your new SQL Server database and select that in the Linked Table Manager.
Open the Data Sources (ODBC) shortcut: in XP Pro, this is in the Control Panel under Administrative Tools. (If you don't see it, you probably don't have permission to create a data source, so you'll have to work with your network people to do this.) This will open the ODBC Administrator.
On the File DSN tab, click Add.... You'll see a list of available drivers. Select SQL Server and click Next. (If the front end is only being used on your machine, you can create a System DSN instead.)
Find a common location and name your data source.
Click Next and Finish. This will set up the first part of the data source, and will open the SQL Server data source wizard.
Name the data source and select the server on which you've put the upsized back-end database.
Change the rest of the settings as needed (you may not need to change much, but the scope of those changes may require a second question) and click through to Finish.
Once you have the data source set up, then Get External Data should give you the option to select it as your source. (In 2007, you can get there from the External Data ribbon. ODBC data sources are available under More.)
To expand a little further based on Matt's follow-up questions:
How you do it is a design choice. I recommend upsizing the back-end mdb because that would allow you to keep whatever forms and such you had in Access; I think it's less of a transition if your data is in SQL Server.
Before you upsized, your tables were linked to the back-end database, and the Linked Table Manager showed the links. After you set up the ODBC data source and linked those tables, it'll show that link. You'll view the links in two different ways because they're actually different types of links (Access vs. ODBC), even though the links may look the same in your front-end mdb.
Personally I have found that the upsizing wizard does a very bad job of determining correct datatypes. I would create the tables myself in SQL server using the datatypes I need, then move the data to the existing tables from Access. other wise you will be stuck with text data when you could use varchar or float when you really need decimal.
Once the data has been moved then I would delete the Access tables and link to the SQL Server tables.
Do not do anything without having a backup copy of the database first.
As a matter of standard paranoia, I would just make a backup copy of the existing files and run the Upsizing Wizard on the front end. If anything undesirable happens, just revert the changes by overwriting with the backup copy.
Update the front end, and it will import the back end tables before it upsizes. I did this a week ago with a successful result.
However, any queries that use -1 instead of Yes will fail. Any full table deletes on tables without a primary key will fail, and you will get different behaviour from that than you will by merely using a pass-through SQL query to truncate table. The trunc will delete all rows, the Access version may leave a blank.
Also you'll need to include dbSeeChanges anywhere you have a recordset opening on a table with an autonumber column data type. SQL changes these to Identity data types, then gripes before you try to open the table. Good luck.
Do it all in the front end
You can simply export the tables to SQL Server.
You can then delete the linked tables you have in your frontend.
Then link the connection to SQL Server
Check:
when you open tables you get records
all your queries run
compile your code
You will also have to consider how you are releasing the front end. If you are using a dsn file you will need to provide that to each user.
You will need to determine how the end user accesses SQL Server. Are you using a single login with the username and password stored in the connection?
You could also split your backend DB into multiple Access DB and link them in the frontend.