I had a working SSIS package last week. I came back into the office this morning, opened up the package and tried to open up one of the Data Flow tasks. Double clicking did nothing. I closed the project and reopened it and received an error message that there was a "Catastrophic Error" and that the layout could not be displayed. The Control Flow diagram now only showed my two Sequence Containers.
I made a copy of the dtsx file then went into it manually with a text editor and found that some of the XML was duplicated. I removed the "extra" copy and reopened my package. The empty Sequence Containers are now gone, but I still can't see any of my components. I looked at the Package Explorer and everything is still there, but it's just not displaying in the designer. I was even able to run the package successfully.
Is there any way to rebuild the package so that I can see everything in the designer? Any other suggestions?
Thanks!
I'm not sure why BIDS has decided the layout is junk but you can get around the issue by removing the layout and forcing BIDS to regenerate that information. The graphical layout stuff is a cool idea for conceptualizing how a package is organized but the implementation of storing that information, serialized XML inside XML, is pants.
There are various articles available about how to remove the XML, but this is a more recent example of how to use do this. http://joshrobi.blogspot.com/2012/04/editing-existing-ssis-package-via-ezapi.html
As always, ensure you have a good copy of the package before editing the XML directly.
Do you have a backup of your package - try and restore that to another location first to make sure that is not corrupted.
How are you accessing the package, are you connecting remotely to a server hosting SSIS, or are you using tools located locally on the server?
I've encountered issues when trying to access packages across networks before.
Also, as a word of warning it's not good practice to edit package contents before carrying out further diagnosis!
Related
We have been using and running SSIS packages for SQL Server 2014 with custom components that have been used since before I arrived at my work place. We upgraded to Visual Studio 2017, and have been fine doing so for months. Recently--maybe in line with a recent update--Visual Studio ssdt fails to load these packages because of errors regarding validating the xml behind these components. The packages continue to run on the server, and creating new packages with these custom components still works as expected. The packages also still open in Visual Studio 2013. We've gone back to earlier versions of the same package in code control. Reinstalled earlier versions of Visual Studio, installed the ssdt tools as a stand-alone, but nothing seems to work.
There is a slew or errors regarding being unable to load values that are part of the definition of these components, and bad references to these in the precedence constraints because of the failure to load these components in the first place, like:
Error loading CCMI Call Import.dtsx: Error loading value "<DTS:ForEachEnumerator xmlns:DTS="www.microsoft.com/SqlServer/Dts" DTS:CreationName="FolderEnumerator" DTS:DTSID="{FACFAC12-F5E1-4BFE-9768-BF73D8053550}" DTS:ObjectName="{FACFAC12-F5E1-4BFE-9768-BF73D8053550}"><DTS:PropertyExpression DTS:Name="Directory">#" from node "DTS:ForEachEnumerator". C:\Users\..Call Import.dtsx 1
When I remove all references to the custom components in the precedence constraints, it will attempt to load the package without the "corrupted" pieces, but because these custom components are containers, in some cases this leaves out most of the work that's been done. I've removed some of these "bad" values it can't load on a lark, but it keeps erroring on the next attribute still associated with the container after I remove the one previously referenced in the error.
I can't open the package, so I cant copy and paste the components into a new package.
Anyone have any ideas?
I was able to fix some of the issues after some study of the XML of these custom components, and wanted to share in case it helped someone, although I doubt the exact same issues I came across would affect many other people.
I wasn't getting any useful error messages for a custom foreach loop container, but when I tried to copy it from a working VS 2013 screen into VS 2017, I did finally get an error stating something like (lost the exact quote) "missing attribute for the server target version". I then found that the working examples of the custom component that worked had this node that was missing from the XML that was "broken":
<TargetServerVersion
Type="3"
Value="120" />
I added the missing attribute and changed the value from 140 to 120 (the version we were actually targeting) and it began to work just fine.
Fixed another custom destination through a similar process, although the error was entirely different. In this scenario, the package would actually open without error, but the custom destination would not function properly (and also no longer had the custom icon). The working package I created with the custom component had an XML that was similar to the broken package's XML in this case. It wasn't until I created a new package in a new project where I immediately set the correct target server that I could see any change in the XML between the broken and working package's code, and it was this:
The 2017 version of the component had a much longer definition of the "UserComponentTypeName" property:
<properties>
<property
dataType="System.String"
name="UserComponentTypeName">Konesans.Dts.Pipeline.TrashDestination.Trash, Konesans.Dts.Pipeline.TrashDestination, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b2ab4a111192992b</property>
</properties>
The correct version for 2016 (I know, different from the last package) had a shorter, much simpler definition:
<properties>
<property
dataType="System.String"
name="UserComponentTypeName">Konesans.TrashDestination</property>
</properties>
It worked correctly when I replaced the property with the shorter definition.
I don't know how frequently these exact issues would come up, but I hadn't seen anything like this while searching for solutions to my problem and thought if someone had a different but related problem with XML changing (perhaps to someone accidentally upgrading a package version?) that it might help add a spark to the creative process and save some time.
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
I am in the process of writing an offline-capable smartclient that will have syncing capability back to the main backend when a connection can be made. As a side note, I considered the Microsoft Sync Framework but since I'm really only going one-way I didn't feel it would buy me enough to justify it.
The question I have is related to SQLite vs. SQLCE and ClickOnce deployments. I've dealt with SQLite before (impressive little tool) and I've dealt with ClickOnce, but never together. If I setup an installer for my app via ClickOnce, how do I ensure during upgrades the local database doesn't get wiped out? Is it possible to upgrade the database (table structure, etc. if necessary) as part of the installer? Or is it better to use SQLCE for something like this? I definitely don't want to go the route of installing SQL Express or anything as the overhead would be far too high for what I am doing.
I can't speak about SQLLite, having never deployed it, but I do have some info about SQLCE.
First, you don't have to deploy it as a prerequisite. You can just include the dll's in your project. You can check this article which explains how. This gives you finite control over what version is being used, and you don't have to deal with installing it per se.
Second, I don't recommend that you deploy the database as a data file and let ClickOnce manage it. When you change that file, ClickOnce will publish it again and put it in the data directory. Then it will take the previous one and put it in the \pre subfolder, and if you have no code to handle that, your user will lose his data. So if you open the database file to look at the table structure, you might be unpleasantly surprised to get a phone call from your user about the data being gone.
If you need to retain the data between updates, I recommend you move the database to the [LocalApplicationData] folder the first time the application runs, and reference it there. Then if you need to do any updates to the structure, you can do them programmatically and control when they happen. This article explains how to do this and why.
The other advantage to putting the data in LocalApplicationData is that if the user has a problem and has to uninstall and reinstall the application, his data is retained.
Regardless of the embedded database you choose your database file (.sqlite or .sdf) will be a part of your project so you will be able to use "Build Action" and "Copy to Output Directory" properties of that file to control what happens with the file during the install/update.
If you choose "Do not copy" it will not copy the database file and if you choose "Copy if newer" it will only copy if you have a new version of your database file.
You will need to experiment a little but by using these two properties you can have full control of how and when your database file is deployed/updated...
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
Lucky me, I have to work with Oracle. And packages.
I have a package that a lot of different developers are touching and it's scaring me. Is it possible to put a package inside of Version Control? Is there some kind of software out there that already does this? If not, is there some kind of export procedure? Can I just grab a file off of a file system?
How are they inputting it? The way we used to work at my last job is editing a text file, and loading it with SQL*Plus. You can just put that source file under version control.
The source must be between "CREATE OR REPLACE PACKAGE MYPACKAGE AS" and "END;" followed by a single slash on a line of its own ("/"); and ditto for "PACKAGE BODY" instead of "PACKAGE".
And yes, there's a way to pull the source out of Oracle. It's in a table, line by line, look up ALL_SOURCE and USER_SOURCE. You can pull it out with a query like
SELECT TEXT FROM ALL_SOURCE
WHERE TYPE='PACKAGE BODY'
AND NAME='MYPACKAGE'
AND OWNER='MYPACKAGEOWNER'
ORDER BY LINE
(untested as I no longer have access to Oracle) and ditto for the 'PACKAGE'.
I think it's best to load it again into Oracle using SQL*Plus; make sure to set "SCAN OFF".
We have a database level trigger to capture changes to packages and save the source in a seperate table. It's not as good as version control, but at least you know when something changes and can retrieve it if a later change tramples on it.
You can download sql developer for free: http://www.oracle.com/technology/products/database/sql_developer/files/what_is_sqldev.html. It integrates with subversion and cvs.
There is also a Visual Studio plugin (http://www.oracle.com/technology/tech/windows/odpnet/index.html). I don't know whether you use Visual Studio or not?
Try http://code.google.com/p/oracle-ddl2svn/ version control for Oracle
Take also a look at this link. It's a PHP/mySQL versioning tool which works with any database type and is fairly simple to learn.