I am trying to have upload a CSV file to my SQL Server via SSIS. Previously- like a few months ago- I was able to click 'New' on the destination editor to create a generic table based on the imported data. Is that option no longer available for some reason? I updated everything and made sure my credentials are correct and that I have read/write access but can't seem to get anything working. I'm using Visual Studio 2017 with SSDT.
My screen used to look like this :
But now it looks like this :
I faced the same issue previously. The reason was that the TargetServerVersion was not set correctly. Make sure that this property is set to the same version of the SQL Server instance you are using.
How to change TargetServerVersion of my SSIS Project?
Related
I’m really confused with how to use database projects in Visual Studio (2019).
I’ve created a new project and imported my database into it. I then can happily edit the SQL and commit it into source control, however, when I try to deploy the items to the server it fails due to unresolved references.
To get around this I have added in a reference to my database and changed the SQL to use the reference like so:
SELECT * FROM [$(DataBase)].dbo.TableName
The project then builds and I can deploy the SQL to my server with:
Tools> SQL server > New Schema Comparison
However what do I then do if I want to edit that SQL and make any changes?
Currently I’m using the “open by default” feature to open the SQL into SSMS (as the editor in visual studio does not appear to have the ability to execute the sql), and then find and replacing the [$(Database)] text with my database name, then making and testing my changes and then cut and pasting it back into Visual Studio and find and replacing the [$(database)] text back in.
I can’t help but think that I'm surely missing something here‽ I find it hard to believe that the workflow is this longwinded.
I just got approved for the Azure SQL Data Warehouse Preview, and just finished "provisioning" my new server and database. I followed a link to a 'Getting Started' page from Microsoft (Get started: Connect ...), and read that the two best (only?) ways of querying the database were through sqlcmd and Visual Studio 2013.
I ignored this advice first, and fired up SSMS, connected to the database, and then tried to open a new query window. I immediately received the following error: 'Unable to apply connection settings. The detailed error message is: 'NoCount' is not a recognized option.' After clicking OK, the query window did open up, but many T-SQL statements did not work such as a simple:
CREATE TABLE dbo.tblTest (acct_id nvarchar(255) NOT NULL)
I would receive a 'Command(s) completed successfully.' message, however no table was created.
Ok, I fired up Visual Studio 2013, connect to my Azure SQL Data Warehouse, and open it up in SQL Server Object Explorer. I right-clicked the specific database, and selected 'New Query', enter the same T-SQL CREATE TABLE statement as above, then hit execute. Once I hit execute, I get the exact same error message as above. This time around I was able to open a new query window at least, but after attempting to execute the query I still get the 'NoCount' is not a recognized option error.
I'm completely new to data warehouses, and still very much a beginner with T-SQL and SQL Server as well. But, I haven't been able to find anything that would explain why I'm receiving these errors, and right now I'm basically at a standstill until I can understand what's going on. Any help is appreciated, thanks.
I've experienced this. Your connection isn't actually recognised as a SQL DW connection. I bet your query window is a .sql file, not a .dsql as it needs to be.
Go back into the Azure portal and use the link to connect using SSDT from there. You should get a connection in the SQL Server Explorer pane which looks different, and when you start a New Query based on it, you should get a .dsql window, not a .sql one.
Have you checked the version of SSDT that you are using? It sounds like you may be on a version prior to 12.0.50623, which doesn't take into account that SET NO COUNT is not supported by SQL Data Warehouse at the moment. Newer versions of SSDT have adjusted for this. We recommend updating SSDT here and then connecting using the SQL Server Object Explorer with the directions in our documentation.
I am running Visual Studio 2015 Enterprise, and what I had to do to get this error resolved was install SSDT October 2015 Preview in Visual Studio. The link I used is: https://msdn.microsoft.com/en-us/library/mt204009.aspx
Prior to installing this, I had the latest released version for VS2015...had to install the Preview to get it to work. Also, it solved the issue where I was not able to see ANY of the tables in the Azure Data Warehouse database - just a couple of views, which made querying difficult (could still get a list of available tables from sys.tables)
I hope this helps somebody!
I created a new database called "staj" and imported 3 excel files into it. I edited the column names and arranged the primary keys. After that, I opened a new web form in Visual Studio and added my database to the project using Entity Framework. It was all fine until I created a new table called UserList and tried to use it in Visual Studio, it says it could not be found. I tried to update Visual Studio by going to Tools -> SQL Server -> New Schema Comparison.
I then got stuck because I can't get past the "Choose Source" part even though I clicked new connection and connected to my SQL Database and tested it. It said it was fine but, I simply couldn't find how to see the changes I've made to SQL in Visual Studio. Refreshing or active syncing didn't work. How can I do this?
This whole time I've been choosing the wrong keywords. My answer lies here -> How to: Update an .edmx File when the Database Changes (Entity Data Model Tools)
I'm using forms authentication to handle users and attempting to deploy my database to SQL Azure, but getting this error message:
The only table of the four listed that I utilize is aspnet_Membership, and the only other table I use is aspnet_Users from implementing forms authentication. What is TextInRowSize and why does SQL Azure care about it? Do I have any option to modify aspnet_Membership to make it compatible?
If it would be easier to remove the current system altogether and replace it with my own, I'm fine with that too.
That looks like an error in the data-tier application framework. I can suggest a workaround to get your database to Azure:
Use SqlPackage.exe (https://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx) from the command line to extract a dacpac file with all table data. Then use SqlPackage.exe to deploy that dacpac file to your database in Azure. The extract command would look something like:
C:\>"c:\Program Files\Microsoft SQL Server\120\DAC\bin\SqlPackage.exe" /a:extract /scs:"Data Source=yourSqlServer;Integrated Security=true;Initial Catalog=yourDatabase" /tf:C:\temp\mydatabase.dacpac /p:ExtractAllTableData=true
And the import command would look something like:
C:\>"c:\Program Files\Microsoft SQL Server\120\DAC\bin\SqlPackage.exe" /a:publish /tcs:"Data Source=yourAzureSQLServer.database.windows.net;User Id=yourUserId;Password=yourPassword;Initial Catalog=yourDatabase" /sf:C:\temp\mydatabase.dacpac
So quick suggestions since I see you are using V12 which should support those properties now.
First make sure you are using SSMS 2014 SP1 at least, this has a number of fixes for using V12. Secondly make sure you install the May 2015 update to DacFX (which is the program that creates bacpac files) you can install it here: http://www.microsoft.com/en-us/download/details.aspx?id=46898
This should get you to the best possible chance of your import/export working.
This was solved by generating a SQL Azure script for the DB, and running it on Azure. Here's how I solved it:
First, open SQL Server, right click the database you want to transfer and click "Tasks > Generate Scripts..."
Next, click "Advanced" on the scripting options panel and find the row "Script for the database engine type." Select "Windows Azure SQL Database" and click OK (Note: if you have data that you want to transfer as well, choose "Schema and Data" from the "Types of data to script" option).
Proceed thru the rest of the script generation dialog, remembering where you saved the script file. Connect to your database server using SQL Server or windowsazure.com. Generate a new query for your new database, enter the script that was generated by SQL Server and execute.
Seems like TextInRowSize stores large data for older SQL Server types such as text and ntext. You would need to change it's type to nvarchar(max).
Here's a link to a more detailed explanation.
http://www.dnnsoftware.com/wiki/unsupported-property-textinrowsize-set-and-is-not-supported-when-used-as-part-of-a-data-package
I have a server that is capable of creating and running an Excel Import task using the Import Wizard. I am trying to automate that process by using a visual Studio 2010 Integration Services package, that I am developing on that server.
The problem happens when trying to design the package. I have added an excel connection and pointed it at the Excel file on a local disk (the same file I have already successfully imported using the import wizard). When I add an Excel Source to the DataFlow and specify the excel connection, when I go to the Name Of the Excel Sheet Drop down I just see "No tables or views can be loaded" and get the following error.
"Could not retrieve the table information for the connection manager.
Failed to connect to the source using the connection manager ..."
I can't find this error logged anywhere and i don't know why it is failing. The directory is shared to Authenticated users and the file is not in use.
Any ideas how to debug this error? I understand there can be issues running this in 64 bit mode, but does that apply to development?
I should add that it is an excel 2007 file .XLSX and the connection is set to Excel 2007.
2019-11-08 The answer by GavB841 below looks promising, if anyone tries it and it works please let me know. (I am no longer working in this area.)
It seems like the 32-bit version of Excel was not installed. Remember
that SSDT is a 32-bit IDE. Therefore, when data is access from SSDT
the 32-bit data providers are used. When running the package outside
of SSDT it runs in 64-bit mode (not always, but mostly) and uses the
64-bit data providers.
Always keep in mind that if you want to run your package in 64-bit
(which you should aim for) you will need both the 32-bit data
providers (for development in SSDT) as well as the 64-bit data
providers (for executing the package in production).
I downloaded the 32-bit access drivers from:
Microsoft Access Database Engine 2010 Redistributable.
After installation, I could see the worksheets
Source:
Extracting Data From Excel with SSIS
The workaround is, I save the excel file as excel 97-2003 then it works fine
I also ran into this problem today, but found a different solution from using Excel 97-2003. According to Maderia, the problem is SSDT (SQL Server Data Tools) is a 32bit application and can only use 32bit providers; but you likely have the 64bit ACE OLE DB provider installed. You could play around with trying to install the 32bit provider, but you can't have both the 64 & 32 version installed at the same time. The solution Maderia suggested (and I found worked for me) was to set the DelayValidation = TRUE on the tasks where I'm importing/exporting the Excel 2007 file.
The recommendations from this article Extracting Data From Excel with SSIS resolved the issue for me.
I downloaded MS Access Database Engine 2010 32 bit driver
from the link in that article.
Also set Project Configuration Properties for Debugging Run64BitRuntime = False
In SQL Server 2014 SSMS (Integration Service Catalog -> SSISDB -> Environments -> Projects for all Packages in Validate checked box 32 bit Runtime.
My SSIS packages are working now in both VS 2013 and SQL Server 2014 environments.
Simple workaround is to open the file and simply press save button in Excel (no need to change the format). once saved in excel it will start to work and you should be able to see its sheets in the DFT.
You need to use an older version of the data connectivity driver (2007 Office System Driver: Data Connectivity Components) and select Excel version 2007-2010 in the connection manager configuration window.
I assume the newest data connectivity driver for Office 2016 is corrupt
Here's the solution that works fine for me.
I just Saved the Excel file as an Excel 97-2003 Version.
As discussed in the below:
Solution:
Go to https://marketplace.visualstudio.com/items?itemName=ProBITools.MicrosoftAnalysisServicesModelingProjects and install the latest version, it has a fix in there to resolve this issue.
Reference: https://developercommunity.visualstudio.com/content/problem/745991/could-not-load-file-or-assembly-microsoftdatawareh.html
A fix for this issue has been internally implemented and is being prepared for release. We’ll update you once it becomes available for download. For now, please install latest SSAS from https://marketplace.visualstudio.com/items?itemName=ProBITools.MicrosoftAnalysisServicesModelingProjects to work around the issue. Sorry for any inconvenience.
I faced the same issue. I think #Rishit answer helped me.
This issue is related to 32 bit/ 64 bit version of driver. I was trying to read .xlsx files to SQL Server tables using SSIS
My machine was pre-installed with Office 2016 64 bit on Win 10 machine along
with MS Access
I was able to read excel 97-2003 (.xls) files using ssis, but unable
to connect .xlsx files
My requirement was to read .xlsx files
Installed AccessDatabaseEngine_X64 to read xlsx, that given me
the following error:
I uninstalled the AccessDatabaseEngine_X64 and installed
AccessDatabaseEngine 32 bit, that resolved the issue
My answer is very similar to the one from #biscoop, but I am going to elaborate a bit as it may apply to the question or to other people.
I had a .xls that was an extraction from one of our webapps. The Excel connection would not work (error message: "no tables or views could be loaded"). As a side note, when opening the file, there would be a warning stating that the file was from an online source and that the content needed activation.
I tried to save the same file as an .xlsx and it worked.
I tried to save the same file with another name as an .xls and it worked too.
So as a last test I only opened the source .xls file, clicking save and the connection worked.
Short answer: just try and see if opening the file and saving does the trick.
Solution
Actually, if you are using SSIS in VS2019 then a problem could occur so do the below things:
Go to the excel sheet and save it again in .xls format.
Once you will use it in .xls format, automatically type will be coming as Microsoft Excel 97-2003 worksheet.
Like in the attached picture.
You will be able to load your sheet data.
I found that my excel file that was created in Excel 365 was incompatible with any of the versions available. I re-saved the excel file in 97-2003 version and of course chose that version in the dropdown list and it read the file OK.
you can try this:
Uninstall office365
then install only Access Database Engine 2016 Redistributable 64 bit
Also set Project Configuration Properties for Debugging Run64BitRuntime = False
It should work.
After researching everywhere finally i have found out temporary solution. Because i have try all the solution installing access drivers but still i am facing same issues.
For excel source,
Before this step you need to change the setting. Save excel file as 2010 format.xlsx
Also set Project Configuration Properties for Debugging Run64BitRuntime = False
Drag and drop the excel source
Double click on the excel source and connect excel. Any way you will get an same error no table or view cannot load....
Click ok
Right click on excel source, click on show advanced edit.
In that click on component properties.
You can see openrowset. In that right side you need to enter you excel sheet name example: if in excel sheet1 then you need to enter sheet1$. I.e end with dollar symbol. And click ok.
Now you can do other works connecting to destination.
I am using visual studio 2017, sql server 2017, office 2016, and Microsoft access database 2010 engine 32bit. Os windows 10 64 bit.
This is temporary solution. Because many peoples are searching for this type of question. Finally I figured out and this solution is not available in any of the website.