For only one particular SSIS package (v. 2005) I am getting the following error when trying to open the script task...
TITLE: Microsoft Visual Studio
Cannot show the editor for this task.
ADDITIONAL INFORMATION:
The operation could not be completed. (Microsoft.VisualBasic.Vsa.DT)
BUTTONS:
OK
I need to get into this to be able to edit it, also I am in the process of upgrading it to 2014. Once upgraded I can get in, but there is no code, so assume the upgrade is not working as it=self cannot see the code within.
I have tried other machines - same problem.
I have tried other packages - they work fine - even in the same solution.
I have tried a few resets found on the net/re-installs - same problem.
Clearly its something to do with this specific package only, but I am stumped.
I would expect to be able to open the Script task like any other, and be able to edit it. I would also expect the upgrade to work and contain the code.
If you want to read the Script Task code, open the package file (.dtsx) using a text editor (Notepad++), and search for the Script Task code, copy the Script Task code and recreate the script and paste the code within the Script editor.
If you have a problem with Script Tasks in visual studio 2005, then copy the code to an external file, upgrade the package to 2014 then paste the code inside the Script Task (since it will be empty after upgrade)
Related
I am just starting on SSIS and created a simple package to start off with. I ran the import/export wizard from SSDT where I am copying table contents from a table to an excel spreadsheet. I eventually get the table contents on the spreadsheet but I have to run the Execute SQL task first, then run the Data Flow task second manually. Not sure why the data Flow task does not pick up after the Execute SQL task completes. The connection is set to run on success. I googled the heck out of this and cannot find an answer. I am running Visual Studio 2013 Shell (Integrated) version 12.0.21005. Any answer (or clue) would be greatly appreciated! Thank you!
In order to create an indipendent runtime file.accdr out of a file.accdb, I've downloaded AccessDeveloperExtensions.exe and AccessRuntime.exe and installed them.
Update:
See article Here is the Google Translater .
Update end.
Opening Access 2007 I could create the install package for creating the file.accdr out of the file.accdb.
The problem I get is that an important function does not work anymore. It's the export of a report, wherelse the export of a table still works.
Opening Access I get the following message:
you don't have a source code control program (such as Microsoft Visual Source Safe) installed on
your machine. The source code control commands are therefore not available
I click on OK and Access opens my db.
My db is based on a table, a form, a report and a query. Exporting the report worked in the past, but doesn't work anymore. The message shown is the following:
Impossible to complete output operation. Assure that there are no syntax errors. If the syntax is
correct, reinstall Microsoft Office Accept...
(I've translated the text from Italian).
Now is there another, easier way from reinstalling the hole thing? Because after reinstalling Access I will also have the need of creating databases.accdr and so I have reinstall runtime.exe and DeveloperExtensions again, what would result in the same problems I had before.
Somebody could help?
I have a visual studio package that does not write all the data needed to a blank excel file.
More specifically, the package goes through these steps:
Copies a template excel file to overwrite a shell file.
Connects to a SQL DB.
Runs a Select Statement.
Converts one column to unicode.
Pastes to shell file.
There are a few more steps afterward (like emailing the excel file) but those work fine.
The issue comes up for step 4. when Visual Studio or SSIS runs the package, I pull about 1400 rows. When I just run the select statement in SQL Server Management Studio or as a connection in Excel I pull about 2800 rows. 2800 is the right number.
I've tried building the process from scratch (excel files, connection files, etc.) but that rebuild elicits the same result. It's like Visual Studio just doesn't like the select statement. Double checked the mappings - all good. The data is pasting and being delivered fine, just not enough. No errors on visual studio either - it gives me that lovely (albeit confusing) check mark.
This was running as an automated package for about a year before this happened and I have no explanation. Seriously a headscratcher.
The only other clue I have is that when I pull the data manually with the select statement, there are no null values in a particular column, but when I run the package with that exact same select statement the output contains a null in the referenced column - almost as if the select statement in Visual Studio is pulling slightly different data than the manual pull, but the statements are exactly the same, so I don't know why that would be.
Any ideas?
I've seen this issue before. The timeout was set to an low value on the connection and caused it to only pull part of data before the timeout hit and killed the connection. Make sure you are not swallowing any exceptions and double check your timeouts.
Thanks for replying folks!
In the end, I solved the issue by completely remaking the package. While trying your solutions above, I was using the same file but building the connections and queries from scratch. Once I started from a new file it ran without error.
I guess to all those new folks to Visual Studio - always consider remaking the file from nothing!
We've used a Visual Studio database project to manage our database schema. What we would like to is include .sql output of a database deployment as part of our products installer which is being created in InstallShield.
However when we add the sql script to the InstallShield project and run the installer, the installer fails to run the script. We get an OLEDB error complaining about the :setvar(s), although I could edit the sql script manually and fix it this isn't really a long term solution.
Garbage In Garbage Out. InstallShield just reads the scripts and executes it against an OLEDB connection. You can tell it On Error Abort, On Error Goto Next Statement or On Error Goto Next Script. Other then that it is what it is. If your SQL has problems they need to be fixed.
InstallShield can do search and replace processing on your SQL. Without a sample of your SQL it's difficult to say exactly what to do but take a look at:
Using InstallScript Text Substitution to Dynamically Replace Strings in SQL Scripts
Visual Studio has a Database Project for Sql Server. This has a number of advantages: it hosts configuration settings, and database objects in one place. The .sql files are part of the regular .NET solutions - visible in the Solution Explorer and editable in Visual Studio. And they have a mechanism for generating a deployment script. With each individual database object in it's own file, the tracking of changes and source control is greatly simplified.
Has anyone had any success with using Database Projects with "non-SQL Server" databases? We use Sybase - which uses T-SQL and is very similar to SQL Server so I'm hopeful.
Or is there an alternative approach? I guess I could use a standard project (.csproj) and call a custom commandline application as part of the post-build to convert the .sql files into a deployment script.
Any ideas would be welcome.
Thanks
OK, I'll answer my own question.
I added all of our SQL objects to their own .sql files within a Visual Studio .dbproj project. However, minor syntactic incompatibilities between the Sybase version of RAISERROR and the Microsoft version of RAISERROR caused the validation code built into Visual Studio to get unhappy. The problem with the database project was that this actually caused a compilation error - which basically made it into a show-stopper.
So I scrapped that idea and added the .sql files to a standard .csproj project file. I then implemented some custom code that would load all of the .sql files, and aggregate them into a deployment script when invoked. I added a call to the custom code to the post build of the .csproj file so that whenever it was compiled - it would output a deployment script - which works like a dream with our build server.
In order to get some of the benefits of the .dbproj, I looked into writing a full SQL parser, but was quickly discouraged by some of the posts on SO. Instead I did some rudimmentary parsing with regex - which got me a few cool features without a lot of effort:
The code could detect dependencies between the various .sql files, and add them to the deployment script in the correct order to avoid sysdepends warnings.
Where there were no dependencies, objects were ordered based on the object type (stored procedure, function, grant statement, etc) and then by name so that the resulting script was always ordered the same - which is very important if you need to diff two versions of the script.
The deployment script can figure out some of the required permissions, so I don't need to keep track of all of the GRANT statements.
Stored procedures that are in the database but not in the script can be dropped automatically - so I don't need to keep track of what state each database is in - we just run the script and everything is in the correct state.
We have a few stored procedures that our automated tests call that shouldn't be deployed. The code can detect these and include them in a Debug build and exclude them in a Release build.
The custom code also generates a diff script that determines what changes the deployment script will make to a database and prints them out. This allows the person who is running the script to get an idea of what it will do. For example, the diff script might tell them that no changes will be made - so they don't need to run the deployment script at all - which is kind of handy if it saves them logging in at 3am to take a database offline and take backups etc.
So the end result is that all of my SQL objects are in separate files making them easy to work with in Visual Studio and manage under source control. For the first time since I started this job, I can look at the history in source control and tell what files have been changed (before this we had one enormous .sql file with absolutely everything in it).