May 25, 2007 at 1:59 am
Hi,
I have an error using the script object in SSIS. I am testing this on a vista workstation. I also have a VMWare workstation installed on this machine. I disabled the visual studio add-in that debugs in vmware.
When I run the package, the script object returns following error:
Error: 0x5 at Show Results: The script files failed to load.
I have not written a separate script file, just put the script in Script Task. (Has it something to do with Vista's UAC (user access control), in that a script host opens with insufficent rights?)
When I close the script object I get the following errors:
An Add-In has caused an access violation while sinking on ‘ProjectRemoved’
"Microsoft Visual Studio for Applications has lost the link to . Your work will be exported to C:\Users\Jan\Documents when you quit the application.
I have eliminated the add-in that enables debugging in vmware. It was the only add-in present.
Somebody any ideas?
Thanks,
Jan
May 25, 2007 at 1:42 pm
Do you have any breakpoints? Try deleting them. Even if you use "Start without debugging". I'm having a similar problem, without addins, vmware, or vista - I get the "lost the link" error if I debug with a breakpoint enabled, and "script files failed to load" error if I debug with a breakpoint disabled, or Start without debugging and a breakpoint exists (enabled or disabled). Once I delete all breakpoints, the script completes successfully.
(But don't use the Debug->Delete All Breakpoints menu item from SSIS designer - it appears to just disable them. Open the script(s) and delete them.)
June 27, 2007 at 8:29 am
I'm having the same problem. Does this mean I can no longer debug my script code, is there anyway I can put a break point back in and start debugging again?
August 14, 2007 at 9:47 am
By the way, we're having this issue as well. It appears it got to the Microsoft forums as well and no action has been taken as of yet.
It seems if you delete and recreate the script task the problem goes away, but this is not ideal...
http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=889400&SiteID=17
Methinks its a bug with script debugging in SSIS.
Anyone else having this issue?
November 8, 2007 at 3:52 am
Hi
i encountered the same problem and tried to move some code from its place and placed the breakpoint in different places till it worked. And when it worked it show me that there is other breakpoint that was disabled by the system...
Delete all the breakpoints and check if there is any disabled...
And if you have any script task disabled with breakpoint in it delete these breakpoints also...
And then try to place your breakpoint at the beginning of the script after the try catch block and it should work.
if it didn’t try to move the breakpoint to another code line...
This is what's available for now.
March 25, 2008 at 5:49 am
[font="Verdana"]I would want to share my experience with SSIS project.
I've tryed to delete the commets and the white spaces that are inserted automatically by Visual Studio on top of script tasks.
Then I've lauch the debug and now, "magically" :w00t:, it works again. 😀
May this be usefull for all.
Bye ;),
O_Gigant[/font]
March 26, 2008 at 11:03 am
Is there a definite fix for this ?! I am running 2005 64bit on SP2
I have tried everything and it looks as though I can no longer debug - no idea how to progress
This is the latest message.... which only occurs if I use a break point... hopeless :w00t:
Warning: SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED. The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
May 7, 2008 at 3:53 pm
This worked for me:
I removed the VMWare virtual debugger Visual Studio add-in and that made the error message as well as the not-breaking-into-debug-mode problem goes away.
May 27, 2008 at 6:20 pm
I have the same issue, Looks like if you have a variable created after the script object is created and the newly created variable is an Input / InOut parameter to the script, the debugging of the script fails some times, I tried deleting the script object and recreating the script object.
it worked..
December 12, 2008 at 5:36 am
Hi,
got the "" issue as well
Disabling/deleting breakpoints does not help, neither does removing the auto generated code; solutions suggested by others.
However, when copying the code from the old to a new script task, I found that the reference to " Microsoft.SqlServer.Management" that I use was lost.
Trying to add the reference "Microsoft.SqlServer.Smo.dll" fails, with the message "The type library 'C:\...SDK\Assemblies\Microsoft.SqlServer.Smo.tlb' could not be loaded".
I guess something is corrupt here, I'll investigate further.
/M
June 18, 2009 at 6:11 pm
I have a partial workaround! After doing extensive googling on this topic, none of the existing solutions seemed to help. The problem seems to be related to the fact that every script task uses "ScriptMain" in its naming.
I tried renaming my scripts, but this did not seem to help. However, after renaming one ScriptMain to SetupMain, I noticed in the raw XML file that I now had two copies of the code for SetupMain. One followed the tag and one followed . The value for long-hex was the same for both entries. I further discovered that all three scripts suffered from the same problem. If I edited the StartupMain code, that area of the XML was updated, but the ScriptMain copy was unchanged.
Here's the workaround - After making a backup of the package XML file (PackageName.dtsx), I deleted all script tasks in my package, and confirmed that the XML file no longer contained any references to ScriptMain. Then, one by one I followed the following steps:
1. Add the script task.
2. Set the parameters so that the task will execute (i.e. variables, etc.). DO NOT RENAME IT AT THIS TIME!
3. Cut and paste my code from the backup file.
4. Save the package.
5. Exit Visual Studio.
6. Edit Package.dtsx. Do a search and replace on the string "ScriptMain", changing it to another name (i.e. "SetupMain"). Don't repeat names! Only replace the ScriptMain string - leave everything else alone!
7. Start VS and reload the package.
8. Rinse and repeat for each script task.
Step 5 was important, because for some reason the Variables page (select "Variables" from the SSIS menu) would be broken if VS saw both versions of the XML file.
I was able to set debug points in all three scripts and debug the script successfully. I do have to admit that I did receive the lost link error a couple of times, but that was after 5-6 passes through the package, and it typically showed up AFTER the package execution. After receiving it, I could re-execute and not get it. Who knows?
Oh - I'm on SQL version 9.0.3068, and Visual Studio reports version 8.0.50727.762. My .NET reports version 2.0.50727 SP1.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply