------ Clean started: Project: DataService, Configuration: Debug Any CPU ------
O/R Designer validation failed for file: a.dbml
O/R Designer validation failed for file: b.dbml
O/R Designer validation failed for file: c.dbml
O/R Designer validation failed for file: d.dbml
O/R Designer validation failed for file: e.dbml
O/R Designer validation failed for file: f.dbml
Error: The operation could not be completed. Unspecified error
This error is intermittent. Sometimes the clean is fine, sometimes this happens.
I'm running VS2008 version 9.0.30729.1 SP - 64bit.
Is there some way I can disable the O/R designer's validation or otherwise stop this from occuring?
I had to close Visual Studio and reopen it. Solved this for me. In another case I had to roll back my DBML file, then close Visual Studio, and reopen it.
Looks like a bug for Microsoft to fix.
I had also the same problem, but the following procedure let VS always compile the code correctly:
Close VS
delete all files in the obj\x86 (and eventually x64)\Debug (and Release)\ directory
Then start VS again via command line using
<Path>\devenv.exe /ResetSkipPkgs (optionally: <Name>.sln to open directly the correct project)
(Not sure whether the /ResetSkipPkgs is necessary, but another article told so. I made a small batch script which does all of this automatically).
The code should compile now without any problems!
For reference, my script file looks like this:
del /Q C:\[...]\[...]\obj\x86\Debug\*.*
"C:\Programme (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" /ResetSkipPkgs C:\[...]\[...]\<Name>.sln
(I always develop in debug mode, thus I only delete the matching x86\Debug directory...)
This problem appeared after I copied a property in a table. For some reason the copied property had the same storage name. Deleting this storage attribute in dbml xml for those copied properties solved the issue.
So the source of this problem is most likely some error in the dbml file. If you have version control, check what you changed and maybe you'll spot the error.
vs2010 was giving me this error while vs2017 was building it fine,
running vs2010 with /ResetSkipPkgs (Andre's answer) solved for me.
I solved moving a table around in the .dbml designer (so basically not changing anything), saving and rebuilding the project.
VS2017 was giving this error for one of my DBML files, and was preventing me from successfully building the project. None of these answers worked for me. Things I tried were:
(1. Check csproj file for any inconsistencies such as missing item groups or appended numbers on filenames
2. Running devenv.exe /ResetSkipPkgs
3. Deleting visual studio temporary files)
This error was driving me crazy as the error visual studio shows is very cryptic. My eventual solution was to open the problematic DBML in design mode, and delete every stored procedure (I left the tables). Ran a build and the error stopped generating. Then I simply re added all the stored procedures back to the DBML, and that seemed to have done the trick.
So far, deleting and re-adding the dbml file is the only thing that has worked for me.
Related
I have a fresh installation of Visual Studio 2015 Pro Update 2 + SSDT (June 2016).
When I attempt to edit C# code of my SSSIS script component (clicking on Edit Script...), VSTA does open without any warning/error but does not display anything (like if VSTA was called without specifying a solution to open).
However I can see the temporary solution is properly created in the background in a subfolder of folder:
C:\Users\XXX\AppData\Local\Temp\Vsta\SSIS_SC130...
I can even manually open the solution directly from this folder without any problem.
Any idea why the solution does not automatically open in VSTA ?
This occurred to me twice while working in the same environment as you and I hope the outcome for you is different.
The first time:
As for me it was that VS had corrupted the Script Component and too bad so sad I couldn't restore it.
The Second Time:
Moving the project from machine to machine, at some point there was a change to the .Net assembly of the project. Setting that back to 4.5 allowed me to view my scripts again.
Good luck and enjoy the little surprises VS and SSIS combo like to throw at you
We have developed Custom SSIS components that integrates with an online REST API (Shopify to be precise) and these components work fine in BIDS and every single time too. However, when I create a SQL Server Agent job for the SSIS package that uses the components, some of the components don’t work, there is no error, just never hits the Pre Execute. The components that don’t work call the REST API and set specific TAGS on some orders, they do so using a JSON. The SQL Server agent is running on the same machine (my own) and it's executing the same SSIS package that works in BIDS. There are no errors and the SQL Server JOB reports success.
My machine is a 64 bit setup, so obviously the Agent will be running in 64bit so there may be issues there.
This is what I have tried already
Changed the SQL Server Agent user to eliminate the issue being a proxy/user issue.
Changed the setting for the step to use 32bit runtime (Ticked “Use 32 bit runtime”)
I have tried compiling my code using Any CPU x86 x64 .. with different results but none of them work etc
The installation project (which is part of the solution) is a WIX Toolset project which can only compile using x86 which I don’t think I can change.
Logged where it is getting to a log file.
I think it might be 32bit/64bit issue but maybe wrong. The log file shows the following
When called from BIDS (works)
• Validate (code running as 32bit)
• Validate (code running as 32bit)
• Hits Pre Execute and it all works thereafter
When called from SQL Server Agent (doesn’t work)
• Validate (code running as 32bit)
• Validate (code running as 64bit)
• Never hits the Pre Execute
Like I said, I suspect it being a 64bit issue but maybe wrong.
Hi guys and sorry for not posting the answer.
First of all thank you for all your help, especially Nick McDermaid as you kept trying and trying. I really appreciated your pointers and without them I wouldn't have solved it ( kind of solved it :o) ).
My SSIS Custom components only work when I have a "Success path" coming out of them. This was only an issue on this particular occasion because it was the last component called in my Data Flow.
This could be down to a bug in my SSIS Custom Component but I am sure I have had this issue with other components in the past (I think it might have been the 'Send Mail Task').
If anyone comes across this issue again then I would love to hear from them.
I'm currently fire fighting at work so hadn't had a chance to look at the SSIS Custom Components again.
Once again, thanks for the help I received.
I realize this question is very old, but I thought I'd put in my answer. I just ran into this very issue and the answer was that the SSIS engine didn't see the custom component doing anything so it removed the component at runtime. I was able to get around this by changing the RunInOptimizedMode property of the Control Flow object to False. After this I was able to run the SSIS package as a SQL Agent job.
If you run the package through dtexec.exe as bilinkc suggested in your comments, it should give you messages that make it obvious if this is occurring.
VS2008 / TFS Build 3.5 / Ent Lib 4.1
I have a rather large solution that contains several apps. They are all currently using Enterprise Library (v.4.1) for their data access layer.
I added and locally tested a new data access layer that uses LINQ to SQL- it was fast and easy to add and the test went fine. But...
When I checked in the project, it would not complete the build - I get a "Partially Succeeded". There are some warnings, but those exact same warnings were there prior to the build failing.
I took the data access class back out (along with the code that calls it) and rebuilt and it builds fine.
I then added an empty new class and put a single variable in it and referenced it from the code. That built. I then created a new LINQ to SQL class in that new project and did not even reference it. When I checked that in, the build failed again with the "Partially Succeeded" message. No extra errors or warnings.
I love LINQ to SQL, I have used it in a few projects outside of this system, but I now have many hours into attempting to get this to build with no success.
Are all the same tools/libraries installed on the build server as on your desktop - Perhaps the server doesn't have the same vs or .net service pack level? Try running the build "manually" on the build server - load up the solution in Visual Studio on the server and execute the build within the IDE rather than under the TFS build system - this may report problems that you don't see so easily in the automated build.
Check the build log. Visual Studio often reports errors in the output pane text or build-server log text that are not picked up by the GUI error windows. So you will think a build succeeded but an output file has "quietly" not been generated. TFS build logs are usually huge so they are a pain to work through, so start by searching for keywords like "error" or the name of the project that fails rather than trying to read through line by line.
OK, we found it. The issue is on stack overflow elsewhere at
Visual Studio Setup and Deployment build fails with no errors
The issue is a bug in MS setup and deploy that breaks when it hits a line in the project that uses Linq. You have to comment out a line in the project to get it to work. Amazing, ridiculous, and no surprise.
Thanks for the input, it was that input that helped us get to the eventual answer (already on StackOverflow, but didn't have Linq in the title).
Morning
I've been reading "SQL Server 2008 Integration Services Problem - Design - Solution". It outlines a way of logging variable changes which I'm trying to replicate in SQL 2005.
Create variables e.g. PackageId, RecordsAffected. - Set Raise ChangeEvent to true.
Create a string variable g.g. strVariableValue. - Set Raise ChangeEvent to false.
On the package event handler: OnVariableValueChanged add a script task "SCR Convert value to string".
Add ReadOnlyVariables: System::VariableValue
Add ReadWriteVariables: User::strVariableValue
In the script, set a local variable to System::VariableValue.value.tostring
Set the variable User::strVariableValue to the local variable
Add an "Execute SQL Task" component "SQL Log Variable Value Changed" calling a SP with no resultsets.
Set parameter mapping to User::PackageId, System::VariableName, User::strVariableValue
When this is run, I get a deadlock on User::PackageID
Error: 0xC001405B at SQL Log Variable Value Changed: A deadlock was detected while trying to lock variable "User::_PackageID" for read access. A lock could not be acquired after 16 attempts and timed out.
The script step succeeds but the Execute SQL task fails. I'm using Visual Studio 2005 Version 8.0.50727.42, Microsoft SQL Server Integration Services Designer Version 9.00.4035.00 and BIDSHelper Version 1.4.3.0.
Any ideas?
Eureka!
I had the same problem and led to a few deadend posts, then I discovered the root.
I had the framework working just fine and wanted to force some info to be logged.
So I changed the value of the framework variable "strVariableValue" and this caused the deadlock with the change event task.
I fixed by creating my own variable "strLogMe" and putting whatever I wanted to log.
Moral: don't touch the framework variables
Did you use the code sample from the book? All the files are available on the Wiley website for free. The code sample includes a SSIS package, sql scripts, and VB code for the script. If this doesn't work for you, then let me know since one of my team members found a way to log variable changes that was different from this methodology.
I was getting this error ("a deadlock was detected" etc), suddenly, which seemed to coincide with I.T. having done a Microsoft Windows patch on the server. There were packages which were using script tasks, with read-only and/or read-write variables in the SSIS UI. Even though it seemed to have been an environmental issue (because the packages had worked for months, then suddenly stopped working, even though I hadn't changed any code), I thought, well (as I had seen from various blog posts from years gone by), there were instances of companies doing server patches, then having their SSIS packages break; and the blogs seemed to say, change the way you're locking the variables, don't reference them in the UI; instead, lock them explicitly in code. So I tried the same thing. It didn't fix it.
It turns out some individual had removed the permissions of the user under whose identity the packages run, from the AD group; those permissions were required because it was trying to copy a file from a directory which required read permissions on the directory. These packages are typically called by a SQL agent job using a proxy identity. When the package was executed manually from SSMS, it worked. But when it was run by calling the SQL agent job, it failed.
The bottom line is, it was just coincidence that the packages started failing around the time of the Windows update. But the other (main) point is, if your package is trying to access a file on the network, and the identity (or proxy identity) under which that package runs does not have permissions to the source or target directory, then your package could fail and the problem could manifest itself in this cryptic way, where it looks like a variable deadlock issue, but it's actually a file share permissions issue. I only wasted a day on this, but... maybe this will be useful to somebody in the future.
When I open up the solution that contains SSIS packages created by a colleague, I get this awkward error that tells me nothing about what I'm supposed to do to fix it.
He left instructions to take all the "variables" out of the connection string in the dtsx file manually before opening up the solution. I have done that, now when try to view the package in the designer I just get an image of a red x and this message.
EDIT: You cannot see any design elements, no tabs across the top to switch to errors or data flows. Just a gray center area on the screen with a red x, and the message, its like VisualStudio dies in the process of reading the dtsx file.
The question is rather unspecific so it’s of course difficult to get on the right track here. All of the given answers focus different issues. I would say that PeterX had the best guess. The reason for the error could be as simple as a modified data source.
I came across with a bug "error output has no corresponding output" quite often when adding a new column to a table that needs to be processed by an existing SSIS package. This bug came along with an error message saying that a "Value does not fall within the expected range".
A newly added column needed to be processed by an existing SSIS Package. The expected behavior is that SSIS will recognize that there is a new column and select this column on the columns page of the OLEDB Source Task SSIS to be processed. However, when opening the OLEDB Source Task for the first time after having modified the table I got twice the following error message: "Value does not fall within the expected range." The error message showed up when opening the editor and when opening the Columns page of the editor. Within the Advanced Editor of the OLEDB Source Task the new column showed up in the OLEDB Source Output Columns Tree, but not in the OLEDB Source Error Output Columns Tree. This is the actual underlying problem of the error message. Unfortunately, there seems to be no way to add the missing column manually.
To solve the problem, remove and re-add the newly added column on the Columns Page of the normal Editor as mentioned by Jeff.
It is worth to be mentioned that the data source of the OLEDB Source task was a modified MDS View. Microsoft CRM Dynamics – as mentioned in the related thread – is using views, too. That leads me to the conclusion, that using views as a data source may produce either of the above mentioned errors, when modifying datatypes or adding/removing columns.
Related Thread: Error" ...The OLE DB Source.Outputs[OLE DB Source Output].Columns[XXXXXXXX] on the non-error output has no corresponding output
The described workaround refers to Visual Studio 2008 Version 9.0.30729.4462 QFE with Mircorsoft.NET Framework 3.5 SP1. The database is SQL Server 2008 R2 (SP2).
I had to delete and recreate the OLE DB Data source in my Data Flow - this is where I got the error. I also noted I had to "re-select" the "OLE DB connection manager" in the drop-down-list to force it to recognise the new connection.
This was probably a combination of getting the solution from TFS (where I noticed the data-sources didn't come-across properly and it complaining about a missing connection GUID) and/or copying and pasting the elements from another package.
(For BIDS 2008).
I had this issue for my OLE DB Source component with an SQL command after adding new columns to the database, and it wouldn't let me select columns or anything else to add the new columns.
I'm working with an Oracle database, and the only way I could get it to update was to change the SQL query to select 1 from dual, and preview it. Then revert it back to my old query.
You get a similar message if someone uses EncryptAllWithUserKey as the ProtectionLevel. However, I believe the message is slightly different (even though you get a grey design surface with a red X).
Have you tried viewing the file in Notepad? Is it just a series of GUIDs or is there anything in it that is humanly readable? If it doesn't have any readable code, then it was probably encyrpted with the user key.
If the employee deployed the packages to a server and used SQL Server as the deployment destination (not File System or SSIS Pacakge Store) then you can download the packages to your machine. Just connect to the SQL Server Integration Services engine, expand Stored Packages, expand MSDB, expand the relevant folder, right-click on the package, and click Export Package. Save the file on your local machine and open it. The package will probably lose annotations and pretty formatting, but otherwise it should be identical to what the employee deployed.
I just struck the same issue. After flailing about for a bit, I found the solution was to edit the Solution Configuration.
The Solution Configuration appeared to have a matching Project configuration, as shown:
However clicking the drop-down arrow for that Project (SSIS-Advance in this example) revealed that there was no Project Configuration for that project called Production - Sub Reports. I'm not sure how that came about - this Solution has a 7-year history and many developers.
Anyway once I created a New Project configuration (using that same drop-down menu), it is all happy now.
If it has Oracle data sources, you may need to install the Microsoft Connectors v4.0 for Oracle by Attunity:
https://www.microsoft.com/en-us/download/details.aspx?id=52950
I also had to use VS 2015 - the version originally used to create the project and package.
I had this exact problem and installing these connectors and using VS 2015 fixed the issue.
I had this occur as well when I tried to call a stored procedure with OUTPUT parameters with OLE DB.
I found this: http://sqlsolutions.blogspot.com/2013/04/ssis-value-does-not-fall-within.html, which resolved my issue. The relevant action was to rename the SSIS parameter mappings to '0', '1', etc.
So for example, when calling dbo.StoredProc #variable0 = ?, #variable1 = ? OUTPUT, #variable2 = ?;, in the parameter mapping dialog, you would name the parameters '0', '1', 2' to correspond to those. Ah, SSIS <3
I get this when I do not follow the convention for parameter naming, e.g. not name parameters 0,1,2,... in the right order for OLE DB connections.
The details are documented here.
In your connection manager, convert your connections to package level instead of project level
Delete connection manager and re-create and setup ssis package solve the problem.
I got this issue after I Add Existing Connection Manager in a SSIS project. I was just importing a Project Connection Manager from a different project (.conmgr) to my project. My solution to fix the issue was:
Deleting the imported .conmgr
Recreating it from scratch