Thursday, March 29, 2012
Error loading resource string in SP2
report, it keep pop up the error message say"Error loading resource string",
after I click many times, I got the printer properties window, many text in
the button are disappear, but I still could print it out.
Any idea?
ThanksMy guess is that you had the beta of SP2. If so then you need to clear out
then per Brian Welcker (MS): You need to clean out any older versions of the
controls from your C:\WINDOWS\Downloaded Program Files directory.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"msnews.microsoft.com" <huangxiaohua@.hotmail.com> wrote in message
news:uYZWGkxSFHA.2304@.tk2msftngp13.phx.gbl...
> After I installed the SP2 and reboot the server, when I try to print the a
> report, it keep pop up the error message say"Error loading resource
string",
> after I click many times, I got the printer properties window, many text
in
> the button are disappear, but I still could print it out.
> Any idea?
> Thanks
>
Error loading report
Error in file e:\directory\report.rpt.
Failed to load database information.
Any ideas.?
ThanksMake sure it is pointing the correct database|||Check if proper DSN is created and Verify the Database in the report at design time.|||With e:\ being the network drive my report e:\myreport.rpt is pointing to e:\myreport.xsd
which is correct as far as I know.|||Have ttried changing network paths to UNC, no joy.
Strangely, if I load the project within VB.Net, the app and the reports run fine. But when I run the installed package I get this error. This makes me think that maybe I need to package up some additional files with the app.?
Error loading Query Execution Plan
I am trying to tune a very long running query (18 minutes on an Axim X51, 8secs on my laptop), but I can't get the query plan file that is generated on the device to load in the Sql Server Management Studio. I am using the Sql Everywhere CTP on the device, and version 9.00.2047 of the management studio shell.
FWIW, when I try to create the execution plan by running the same query on a .sdf file local on my laptop, I get a similar error trying to view the query plan.
Apart from the query plan issues, it would appear (just from the query execution time) that the indexes defined on the sdf file are not being used when executing the query on the device, but are being used when executing the query on the laptop. This is pure SWAG on my part, though.
I can't figure out how to attach a file to the post, unfortunately.
Thanks for any help you can offer.
Matthew Belk, BizSpeed, Inc.
Matthew,
What is the error that you get when loading the query execution plan in Management Studio? My guess is that it would be an issue in rendering the graphical execution plan. However, you can still see the plan information from the plan file (xml format).
Also, the query plan usually does not differ on the laptop and the device.
|||I was able to identify the query bottleneck by manually interpreting the plan file, but it was an arduous task sifting through all that XML. There was a similar issue posted to the Feedback section in the SQL Server area of the Microsoft Connect website (issue id 231137) that I validated and commented on. That issue was marked closed/fixed, but there were no additional comments.
Thanks, Matthew
Here is the text of the plan file:
===================================
Error loading execution plan XML file C:\Documents and Settings\mbelk\My Documents\batitem.sqlplan. (SQLEditors)
Program Location:
at Microsoft.SqlServer.Management.UI.VSIntegration.Editors.ShowPlan.ShowPlanControl.LoadXml(String xmlFile)
at Microsoft.SqlServer.Management.UI.VSIntegration.Editors.ShowPlan.Editor.Microsoft.VisualStudio.Shell.Interop.IPersistFileFormat.Load(String fileName, UInt32 grfMode, Int32 readOnly)
===================================
Exception has been thrown by the target of an invocation. (mscorlib)
Program Location:
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectWrapperTypeConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
at System.ComponentModel.TypeConverter.ConvertFrom(Object value)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectWrapperTypeConverter.ConvertToObjectWrapper(Object item)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectWrapperTypeConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
at System.ComponentModel.TypeConverter.ConvertFrom(Object value)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.PropertyFactory.CreateProperty(PropertyDescriptor property, Object value)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectParser.ParseProperties(Object parsedItem, PropertyDescriptorCollection targetPropertyBag, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanParser.Parse(Object item, Object parentItem, Node parentNode, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.XmlPlanNodeBuilder.Execute(Object dataSource)
at Microsoft.SqlServer.Management.UI.VSIntegration.Editors.ShowPlan.ShowPlanControl.LoadXml(String xmlFile)
===================================
Exception has been thrown by the target of an invocation. (mscorlib)
Program Location:
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectWrapperTypeConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
at System.ComponentModel.TypeConverter.ConvertFrom(Object value)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.PropertyFactory.CreateProperty(PropertyDescriptor property, Object value)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectParser.ParseProperties(Object parsedItem, PropertyDescriptorCollection targetPropertyBag, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ExpandableObjectWrapper..ctor(Object item, String defaultPropertyName, String displayName)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectWrapperTypeConverter.Convert(SeekPredicateType item)
===================================
Object reference not set to an instance of an object. (SqlMgmt)
Program Location:
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ExpandableArrayWrapper.PopulateProperties(ICollection collection)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectWrapperTypeConverter.ConvertToObjectWrapper(Object item)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectWrapperTypeConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
at System.ComponentModel.TypeConverter.ConvertFrom(Object value)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.PropertyFactory.CreateProperty(PropertyDescriptor property, Object value)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectParser.ParseProperties(Object parsedItem, PropertyDescriptorCollection targetPropertyBag, NodeBuilderContext context)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ExpandableObjectWrapper..ctor(Object item, String defaultPropertyName, String displayName)
at Microsoft.SqlServer.Management.SqlMgmt.ShowPlan.ObjectWrapperTypeConverter.Convert(ScanRangeType item)
Sorry about that. I checked out the details.
This error shows up whenever more than one column of a composite index is being used for a seek or scan.
e.g.
select * from
stores, sales where
sales.stor_id = stores.stor_id
and sales.ord_num = 'test'
- with a composite index on sales.stor_id and sales.ord_num.
For a work around, choose only one column from the index while tuning the query initially.
e.g.
select * from
stores, sales where
sales.stor_id = stores.stor_id
The plan that you get should be similar to the actual plan. For the final pass of tuning the query, use the full query!
Thanks
Pragya
Error loading package
Hi there all...
We've just started using SSIS packages, and everything seems to be going ok.
I've recently set up a couple of jobs which just run an SSIS package every 5 minutes to collect data.
These run fine 90% of the time, but intermittantly produce an error.
When using a SSIS task in the job it simply reported
"Could not load Package."
I have changed these to use DTExec as I heard it gave more verbose execution results, and now I get an error like
"Executed as user: NZ\SQLAdmin. Microsoft (R) SQL Server Execute Package Utility Version 9.00.1399.06 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 8:25:00 a.m. Could not load package "\MSDB\RadiusBilling\Get_RADIUS_AuthLog" because of error 0x80040E37. Description: Table/view either does not exist or contains errors. Source: Microsoft SQL Native Client Started: 8:25:00 a.m. Finished: 8:25:00 a.m. Elapsed: 0.047 seconds. Process Exit Code 5. The step failed."
So far I have not been able to find anyone else with similar errors.
Whenever the package executes it seems to run fine, so this seems to be an error just getting the package to execute in the first place, and as I said it only happens internittantly.
The packages talk to a SQL2005 server using windows authentication (which I assume is inherited from the SQLAgent service user), as well as a MySQL server through an ODBC connection.
The package is saved in the MSDB SSIS Package Store and uses the "Rely on Server for Security" option
Does anyone know why this is happening and how I can fix it?
disenfranchised wrote:
Hi there all...
We've just started using SSIS packages, and everything seems to be going ok.
I've recently set up a couple of jobs which just run an SSIS package every 5 minutes to collect data.
These run fine 90% of the time, but intermittantly produce an error.When using a SSIS task in the job it simply reported
"Could not load Package."I have changed these to use DTExec as I heard it gave more verbose execution results, and now I get an error like
"Executed as user: NZ\SQLAdmin. Microsoft (R) SQL Server Execute Package Utility Version 9.00.1399.06 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 8:25:00 a.m. Could not load package "\MSDB\RadiusBilling\Get_RADIUS_AuthLog" because of error 0x80040E37. Description: Table/view either does not exist or contains errors. Source: Microsoft SQL Native Client Started: 8:25:00 a.m. Finished: 8:25:00 a.m. Elapsed: 0.047 seconds. Process Exit Code 5. The step failed."So far I have not been able to find anyone else with similar errors.
Whenever the package executes it seems to run fine, so this seems to be an error just getting the package to execute in the first place, and as I said it only happens internittantly.The packages talk to a SQL2005 server using windows authentication (which I assume is inherited from the SQLAgent service user), as well as a MySQL server through an ODBC connection.
The package is saved in the MSDB SSIS Package Store and uses the "Rely on Server for Security" optionDoes anyone know why this is happening and how I can fix it?
So you say it fails intermittently? Well that's weird.
Its failing because it cannot validate one of its external data sources. The fact that its intermittent leads me to suggest that there is some outside influence that is causing this. network connectivity perhaps? I'm just speculating here.
-Jamie
|||I have suspected that it might be something to do with the permissions on the domain account that the SQLAgent runs as.
Something like the account was getting locked perhaps.
However if that was the case I'd expect to see 5-6 failures as the job runs every 5 minutes, and the domain keeps accounts locked for 30 minutes. We only ever seem to get isolated failures, but about 6 times per day (which out of 288 executions isn't to bad)
|||Hi
I have the same problem with my SSIS packages.
I'm still developing the package so it isn't finished yet. But on each step I put it into production to see, how it behaves.
In adtition to you, I noticed, that this error occurs more often, when the package is stored in MSDB store. Previously I have had packages stored in SQL's FileSystem store and error occurs maybe twice or three times per week. Now it occurs several times per day.
I use the domain user and id in Administators group on the server.
I execute the package on the server where the inserting database is.
I execute the package every minute.
BR
ZigaP
|||Again, it sounds like an intermittent connectivity issue.|||I think the network connectivity is not an issue.
It cannot be, because I run packages on the server where the database is.
what about this: if I replace the name of the server with "(local)"... can this solve the problem?
No matter what you think or what you are told, I can tell you that most parts of SSIS only run about 90% of the time when you execute packages from the 'Business Intelligence Development Studio' (VS2005 really)
We actually have a problem right now because we do not have any test cases which will run 100% of the time if you let them run for a day.
Most things seem to work if you keep testing to less than an hour, but anymore and you will eventually hit a failure.
Oddly, the problem only occurs at the package level. We have not seen a package or flow that dies in the middle, or in different places, or anything variable.
It either runs to success, dies upon startup (by any means, scheduled, manual, debug), or just plain does the wrong thing. Once a given package shows a particular problem, the problem is the same every time that package fails, and there is usually only one problem.
It is known to us and some big customers that you need to shut down dev studio and reload your project to get things to work again.
The size and/or complexity of the work does not seem to matter either.
We have simple flows with one src and one dest that moves 10000 rows, all the way to massive, multi-pronged flows with multiple sources, lookups, and millions of records.
They all eventually fail. Once you get the first failure, all others on that package will be of the same nature.
Its odd.
|||
FarmerChet wrote:
My company develops SSIS components.
No matter what you think or what you are told, I can tell you that most parts of SSIS only run about 90% of the time when you execute packages from the 'Business Intelligence Development Studio' (VS2005 really)
We actually have a problem right now because we do not have any test cases which will run 100% of the time if you let them run for a day.
Most things seem to work if you keep testing to less than an hour, but anymore and you will eventually hit a failure.Oddly, the problem only occurs at the package level. We have not seen a package or flow that dies in the middle, or in different places, or anything variable.
It either runs to success, dies upon startup (by any means, scheduled, manual, debug), or just plain does the wrong thing. Once a given package shows a particular problem, the problem is the same every time that package fails, and there is usually only one problem.It is known to us and some big customers that you need to shut down dev studio and reload your project to get things to work again.
The size and/or complexity of the work does not seem to matter either.
We have simple flows with one src and one dest that moves 10000 rows, all the way to massive, multi-pronged flows with multiple sources, lookups, and millions of records.
They all eventually fail. Once you get the first failure, all others on that package will be of the same nature.Its odd.
I've not observed this in my packages. So are you here with a question, or just posting your experience? There are so many things that influence package execution, and until you are sure you have a perfect environment, I wouldn't take your post with too much credit.|||
Hm... After my last post error occured only once.
I didn't do anything from my last post. Also admins on server didn't do anything...
Is server has to get used to these packages to run well?
BR
ZigaP
Error loading package
Could some one please help me with this problem... After working with the Rational Guide To Scripting SSIS Beta Preview (Donald Farmer), chapter 6 Adv uses of the Script Task.. For some reason I cannot open or create any packages now... Here's a sample of the error message:
"There were errors while the package was being loaded. The package might be corrupted. Se the error-list for details" This came with an OK-button.
Error 1 - Error loading DataTransfer.dtsx: Unable to instantiate XML DOM document, please verify that MSML binaries are properly installed and registered.
Error 2 - Error loading DataTransfer.dtsx: Unable to load from XML
The Error-list has 6 errors and 2 warnings...
regards maggi
Please see this. I think it may be what you're seeing. RegSvr32 the xml dlls essentially fixes the problem.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=74140&SiteID=1
Kirk Haselden
Author "SQL Server Integration Services"
Error loading package
Hi there all...
We've just started using SSIS packages, and everything seems to be going ok.
I've recently set up a couple of jobs which just run an SSIS package every 5 minutes to collect data.
These run fine 90% of the time, but intermittantly produce an error.
When using a SSIS task in the job it simply reported
"Could not load Package."
I have changed these to use DTExec as I heard it gave more verbose execution results, and now I get an error like
"Executed as user: NZ\SQLAdmin. Microsoft (R) SQL Server Execute Package Utility Version 9.00.1399.06 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 8:25:00 a.m. Could not load package "\MSDB\RadiusBilling\Get_RADIUS_AuthLog" because of error 0x80040E37. Description: Table/view either does not exist or contains errors. Source: Microsoft SQL Native Client Started: 8:25:00 a.m. Finished: 8:25:00 a.m. Elapsed: 0.047 seconds. Process Exit Code 5. The step failed."
So far I have not been able to find anyone else with similar errors.
Whenever the package executes it seems to run fine, so this seems to be an error just getting the package to execute in the first place, and as I said it only happens internittantly.
The packages talk to a SQL2005 server using windows authentication (which I assume is inherited from the SQLAgent service user), as well as a MySQL server through an ODBC connection.
The package is saved in the MSDB SSIS Package Store and uses the "Rely on Server for Security" option
Does anyone know why this is happening and how I can fix it?
disenfranchised wrote:
Hi there all...
We've just started using SSIS packages, and everything seems to be going ok.
I've recently set up a couple of jobs which just run an SSIS package every 5 minutes to collect data.
These run fine 90% of the time, but intermittantly produce an error.When using a SSIS task in the job it simply reported
"Could not load Package."I have changed these to use DTExec as I heard it gave more verbose execution results, and now I get an error like
"Executed as user: NZ\SQLAdmin. Microsoft (R) SQL Server Execute Package Utility Version 9.00.1399.06 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 8:25:00 a.m. Could not load package "\MSDB\RadiusBilling\Get_RADIUS_AuthLog" because of error 0x80040E37. Description: Table/view either does not exist or contains errors. Source: Microsoft SQL Native Client Started: 8:25:00 a.m. Finished: 8:25:00 a.m. Elapsed: 0.047 seconds. Process Exit Code 5. The step failed."So far I have not been able to find anyone else with similar errors.
Whenever the package executes it seems to run fine, so this seems to be an error just getting the package to execute in the first place, and as I said it only happens internittantly.The packages talk to a SQL2005 server using windows authentication (which I assume is inherited from the SQLAgent service user), as well as a MySQL server through an ODBC connection.
The package is saved in the MSDB SSIS Package Store and uses the "Rely on Server for Security" optionDoes anyone know why this is happening and how I can fix it?
So you say it fails intermittently? Well that's weird.
Its failing because it cannot validate one of its external data sources. The fact that its intermittent leads me to suggest that there is some outside influence that is causing this. network connectivity perhaps? I'm just speculating here.
-Jamie
|||
I have suspected that it might be something to do with the permissions on the domain account that the SQLAgent runs as.
Something like the account was getting locked perhaps.
However if that was the case I'd expect to see 5-6 failures as the job runs every 5 minutes, and the domain keeps accounts locked for 30 minutes. We only ever seem to get isolated failures, but about 6 times per day (which out of 288 executions isn't to bad)
|||Hi
I have the same problem with my SSIS packages.
I'm still developing the package so it isn't finished yet. But on each step I put it into production to see, how it behaves.
In adtition to you, I noticed, that this error occurs more often, when the package is stored in MSDB store. Previously I have had packages stored in SQL's FileSystem store and error occurs maybe twice or three times per week. Now it occurs several times per day.
I use the domain user and id in Administators group on the server.
I execute the package on the server where the inserting database is.
I execute the package every minute.
BR
ZigaP
|||Again, it sounds like an intermittent connectivity issue.|||I think the network connectivity is not an issue.
It cannot be, because I run packages on the server where the database is.
what about this: if I replace the name of the server with "(local)"... can this solve the problem?
No matter what you think or what you are told, I can tell you that most parts of SSIS only run about 90% of the time when you execute packages from the 'Business Intelligence Development Studio' (VS2005 really)
We actually have a problem right now because we do not have any test cases which will run 100% of the time if you let them run for a day.
Most things seem to work if you keep testing to less than an hour, but anymore and you will eventually hit a failure.
Oddly, the problem only occurs at the package level. We have not seen a package or flow that dies in the middle, or in different places, or anything variable.
It either runs to success, dies upon startup (by any means, scheduled, manual, debug), or just plain does the wrong thing. Once a given package shows a particular problem, the problem is the same every time that package fails, and there is usually only one problem.
It is known to us and some big customers that you need to shut down dev studio and reload your project to get things to work again.
The size and/or complexity of the work does not seem to matter either.
We have simple flows with one src and one dest that moves 10000 rows, all the way to massive, multi-pronged flows with multiple sources, lookups, and millions of records.
They all eventually fail. Once you get the first failure, all others on that package will be of the same nature.
Its odd.|||
FarmerChet wrote:
My company develops SSIS components.
No matter what you think or what you are told, I can tell you that most parts of SSIS only run about 90% of the time when you execute packages from the 'Business Intelligence Development Studio' (VS2005 really)
We actually have a problem right now because we do not have any test cases which will run 100% of the time if you let them run for a day.
Most things seem to work if you keep testing to less than an hour, but anymore and you will eventually hit a failure.Oddly, the problem only occurs at the package level. We have not seen a package or flow that dies in the middle, or in different places, or anything variable.
It either runs to success, dies upon startup (by any means, scheduled, manual, debug), or just plain does the wrong thing. Once a given package shows a particular problem, the problem is the same every time that package fails, and there is usually only one problem.It is known to us and some big customers that you need to shut down dev studio and reload your project to get things to work again.
The size and/or complexity of the work does not seem to matter either.
We have simple flows with one src and one dest that moves 10000 rows, all the way to massive, multi-pronged flows with multiple sources, lookups, and millions of records.
They all eventually fail. Once you get the first failure, all others on that package will be of the same nature.Its odd.
I've not observed this in my packages. So are you here with a question, or just posting your experience? There are so many things that influence package execution, and until you are sure you have a perfect environment, I wouldn't take your post with too much credit.|||
Hm... After my last post error occured only once.
I didn't do anything from my last post. Also admins on server didn't do anything...
Is server has to get used to these packages to run well?
BR
ZigaP
Error loading package
Hi there all...
We've just started using SSIS packages, and everything seems to be going ok.
I've recently set up a couple of jobs which just run an SSIS package every 5 minutes to collect data.
These run fine 90% of the time, but intermittantly produce an error.
When using a SSIS task in the job it simply reported
"Could not load Package."
I have changed these to use DTExec as I heard it gave more verbose execution results, and now I get an error like
"Executed as user: NZ\SQLAdmin. Microsoft (R) SQL Server Execute Package Utility Version 9.00.1399.06 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 8:25:00 a.m. Could not load package "\MSDB\RadiusBilling\Get_RADIUS_AuthLog" because of error 0x80040E37. Description: Table/view either does not exist or contains errors. Source: Microsoft SQL Native Client Started: 8:25:00 a.m. Finished: 8:25:00 a.m. Elapsed: 0.047 seconds. Process Exit Code 5. The step failed."
So far I have not been able to find anyone else with similar errors.
Whenever the package executes it seems to run fine, so this seems to be an error just getting the package to execute in the first place, and as I said it only happens internittantly.
The packages talk to a SQL2005 server using windows authentication (which I assume is inherited from the SQLAgent service user), as well as a MySQL server through an ODBC connection.
The package is saved in the MSDB SSIS Package Store and uses the "Rely on Server for Security" option
Does anyone know why this is happening and how I can fix it?
disenfranchised wrote:
Hi there all...
We've just started using SSIS packages, and everything seems to be going ok.
I've recently set up a couple of jobs which just run an SSIS package every 5 minutes to collect data.
These run fine 90% of the time, but intermittantly produce an error.When using a SSIS task in the job it simply reported
"Could not load Package."I have changed these to use DTExec as I heard it gave more verbose execution results, and now I get an error like
"Executed as user: NZ\SQLAdmin. Microsoft (R) SQL Server Execute Package Utility Version 9.00.1399.06 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 8:25:00 a.m. Could not load package "\MSDB\RadiusBilling\Get_RADIUS_AuthLog" because of error 0x80040E37. Description: Table/view either does not exist or contains errors. Source: Microsoft SQL Native Client Started: 8:25:00 a.m. Finished: 8:25:00 a.m. Elapsed: 0.047 seconds. Process Exit Code 5. The step failed."So far I have not been able to find anyone else with similar errors.
Whenever the package executes it seems to run fine, so this seems to be an error just getting the package to execute in the first place, and as I said it only happens internittantly.The packages talk to a SQL2005 server using windows authentication (which I assume is inherited from the SQLAgent service user), as well as a MySQL server through an ODBC connection.
The package is saved in the MSDB SSIS Package Store and uses the "Rely on Server for Security" optionDoes anyone know why this is happening and how I can fix it?
So you say it fails intermittently? Well that's weird.
Its failing because it cannot validate one of its external data sources. The fact that its intermittent leads me to suggest that there is some outside influence that is causing this. network connectivity perhaps? I'm just speculating here.
-Jamie
|||I have suspected that it might be something to do with the permissions on the domain account that the SQLAgent runs as.
Something like the account was getting locked perhaps.
However if that was the case I'd expect to see 5-6 failures as the job runs every 5 minutes, and the domain keeps accounts locked for 30 minutes. We only ever seem to get isolated failures, but about 6 times per day (which out of 288 executions isn't to bad)
|||Hi
I have the same problem with my SSIS packages.
I'm still developing the package so it isn't finished yet. But on each step I put it into production to see, how it behaves.
In adtition to you, I noticed, that this error occurs more often, when the package is stored in MSDB store. Previously I have had packages stored in SQL's FileSystem store and error occurs maybe twice or three times per week. Now it occurs several times per day.
I use the domain user and id in Administators group on the server.
I execute the package on the server where the inserting database is.
I execute the package every minute.
BR
ZigaP
|||Again, it sounds like an intermittent connectivity issue.|||I think the network connectivity is not an issue.
It cannot be, because I run packages on the server where the database is.
what about this: if I replace the name of the server with "(local)"... can this solve the problem?
No matter what you think or what you are told, I can tell you that most parts of SSIS only run about 90% of the time when you execute packages from the 'Business Intelligence Development Studio' (VS2005 really)
We actually have a problem right now because we do not have any test cases which will run 100% of the time if you let them run for a day.
Most things seem to work if you keep testing to less than an hour, but anymore and you will eventually hit a failure.
Oddly, the problem only occurs at the package level. We have not seen a package or flow that dies in the middle, or in different places, or anything variable.
It either runs to success, dies upon startup (by any means, scheduled, manual, debug), or just plain does the wrong thing. Once a given package shows a particular problem, the problem is the same every time that package fails, and there is usually only one problem.
It is known to us and some big customers that you need to shut down dev studio and reload your project to get things to work again.
The size and/or complexity of the work does not seem to matter either.
We have simple flows with one src and one dest that moves 10000 rows, all the way to massive, multi-pronged flows with multiple sources, lookups, and millions of records.
They all eventually fail. Once you get the first failure, all others on that package will be of the same nature.
Its odd.
|||
FarmerChet wrote:
My company develops SSIS components.
No matter what you think or what you are told, I can tell you that most parts of SSIS only run about 90% of the time when you execute packages from the 'Business Intelligence Development Studio' (VS2005 really)
We actually have a problem right now because we do not have any test cases which will run 100% of the time if you let them run for a day.
Most things seem to work if you keep testing to less than an hour, but anymore and you will eventually hit a failure.Oddly, the problem only occurs at the package level. We have not seen a package or flow that dies in the middle, or in different places, or anything variable.
It either runs to success, dies upon startup (by any means, scheduled, manual, debug), or just plain does the wrong thing. Once a given package shows a particular problem, the problem is the same every time that package fails, and there is usually only one problem.It is known to us and some big customers that you need to shut down dev studio and reload your project to get things to work again.
The size and/or complexity of the work does not seem to matter either.
We have simple flows with one src and one dest that moves 10000 rows, all the way to massive, multi-pronged flows with multiple sources, lookups, and millions of records.
They all eventually fail. Once you get the first failure, all others on that package will be of the same nature.Its odd.
I've not observed this in my packages. So are you here with a question, or just posting your experience? There are so many things that influence package execution, and until you are sure you have a perfect environment, I wouldn't take your post with too much credit.|||
Hm... After my last post error occured only once.
I didn't do anything from my last post. Also admins on server didn't do anything...
Is server has to get used to these packages to run well?
BR
ZigaP