I have a TEST BizTalk 2013 R2 environment. It's paired with SQL Server 2014 and Windows Server 2012 R2. It's a mirror of our production environment which has been stable and without issue for over 6 years.
I'm working on adding a new integration partner, and I've created some static send ports that utilize a custom send pipeline component that has been used reliably in production for the past 6 years as well. The custom send pipeline adds archiving capability to EdiSend.
The problem is I've gone into the static send port and set the Send Pipeline several times now. It will work for an unknown amount of time, but for some reason it keeps reverting back to EdiSend. I find this out when I go to look for the archived files. The other oddity I've noticed is that if I go into Resource > Modify > Refresh, instead of opening up a File Select window in the directory last used, it will open up to the BizTalk install directory. My first thought is something in the database must be rolling changes back?
Note, I'm the only one working on the test environment. Has anyone else seen this before? I'm wondering if a recent Windows Update is the culprit, as this started pretty recently.
Clear the files out of %APPDATA%\Microsoft\BizTalk Server\Deployment\BindingFiles\
There is a known issue regarding it using a cached binding file in certain circumstances when deploying which has been around since as least BizTalk 2009
Related
Beginning yesterday afternoon (12/9 Central US time) we began seeing a marked increase in SSIS packages execution failures. These packages have been in operation for several months and experienced no failures on 12/8. Initially I brushed it off as temporary, but now it seems as if "none" of them are working. Several of these packages run hourly, with the first failure around 10:30 on 12/9. Between 10:30 and 1500 'most' succeeded, but after 1500 on 12/9 most failed.
I'm testing with a relatively simple dataflow package. I have two sources (SQL and Sharepoint). From the sources, I compare the two and then update the Sharepoint list with any changes that have been made (SQL query is the authoritative record). The Source Sharepoint list is the same list that is being updated. As a further test, I removed all steps except for querying the Sharepoint list and sorting it. The initial query still fails.
Errors are happening inconsistently within the dataflow package. For example since I've been testing this morning, I had one (and only once) that made it through the package to the point it was should have tried to Add, Update or Delete list items. The table comparison resulted in updates to the Sharepoint list. The package failed when attempting to update the records. Most of them (and all recent attempts) are failing when the dataflow queries the Sharepoint list initially. There are only two records on the Sharepoint List and two records on the SQL table.
I'm connecting to Sharepoint using MS Graph. Testing the connection (Connection Manager) within VS 2019 has succeeded every time. I've verified that the secret I'm using is not expired. I created a new secret and am receiving the same error. 'Usually' if I attempt to preview the Sharepoint source that is successful, but not always. Even if it is successful attempting to debug and run the package fails. I'm not seeing any alerts on Microsoft or Azure that would provide any indication that the problem's there, though I feel like something must have changed there.
I have opened a support ticket with CozyRoc and they have directed me to open a ticket with Microsoft. Microsoft's support request workflow is directing me here.
In the production All Execution reports, the error I'm getting back is:
"Data Flow Task:Error: Attempt to read message string for 0xc02090f5 failed with error 0xc02090f2. Make sure all message related files are registered."
Initial research pointed me toward a data typing issue, but I've not changed anything in our Sharepoint, SSIS or SQL environment to have changed the data types.
This appears to be very repeatable so I can try providing more information if needed.
Look likes the answer was to wait. After about 1 week, the issue resolved as quickly as it appeared. I didn't find a way to report my issue directly to Microsoft without adding a support plan. I was in the process of finding alternative methods to address our needs when it resolved 'by itself'.
I just installed the latest version of SQL Server Design Tools for Visual Studio 2017 (in order to get SSIS templates etc.)
Prior to this I could right-click a report in Solution Explorer and choose run, and this would deploy and run just that one report, but not the others in the project.
Now it seems that when I do the same, all reports (and data sources) in the project are being re-deployed every time I try this. It's not a huge problem, but I liked the old way, in case somebody knows of a little setting tweak in there - I've not found it yet in search.
We had a similar problem when we recently upgraded our setup.
The first thing to note is that Run isn't typically used as a deployment model. It's supposed to be something used for testing, so the behavior you're seeing is likely related (in part) to that. To actually deploy a report, you should be using Deploy, which is right above the Run option.
Additionally, we often saw this behavior when VS could not completely build the entire solution. If you have any reports in your solution that don't build, or are missing (as in they're in the solution but not on disk), the overall build "failed".
That means that VS will continue to try and rebuild the whole project each time you build, run, or deploy anything. If you remove everything from your solution that doesn't pass, and then do this once, you should notice that behavior goes away.
Thankfully this bug was fixed in Reporting Services Projects 1.18.
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.
Hope it's the right place to ask this question - usually I use SO to ask about programming...
I'm doing a project that involves Crystal Reports Server. From code, I'm able to schedule reports successfully, but when I look at the BI launch pad I don't see the report in My Recently Run Documents (I see failed reports in that list - ones that has wrong database credentials).
When I go to Central Management Console and I find my reports in folders and I go to Properties > History I see the report status as "Running" - and it has been like that for a long while (too long than it should) for 2 different reports I have sent.
How can I diagnose what the problem is? and why it is stuck? there are no error messages anywhere about it.
How can I get a full history of all reports in the system (not just one single report at a time)? and how can I see currently running reports?
How can I stop a running report?
I really hope this is the right place for these kind of questions... if not, would be very happy to get a referral.
Thanks
How can I get a full history of all reports in the system?
Open the CMC and then click on the Instance Manager. At the bottom of the page, you can filter on the object type and status. That way, you can get a full overview of all running reports on your platform.
How can I stop a running report?
If you select a running instance (either in a document's history page or in the Instance Manager), you'll notice that there is no stop button. Instead, you have to delete the running instance. It might not stop running immediately though (depending on what it's doing), but it will be removed immediately from the list of instances.
How can I diagnose what the problem is?
What I would recommend is to enable tracing on all related servers (thus your job server, processing server, etc) and then retry scheduling the report. This should generate additional logging on the server which you can use to diagnose the issue.
The trace files have the extension .glf (generic log file) and are located in the logging folder on your Crystal Server. Have a look at the command-line property of each of the servers for which you're enabling the tracing, you should find a log folder there somewhere.
Make sure to turn the tracing off again as soon as you're finished, as tracing will not only create extra strain on your servers (causing the system to slow down), but it will also result in very large log files.
Before starting with tracing, have a look at the existing log files to see if it doesn't already contain error messages that might help you diagnose the issue. Sort the log files by date, and look at the most recent one for each of the servers involved. If there's nothing in there, start with tracing, but remove the existing .glf files to minimise log contamination (some files will be locked, just ignore them).
There is a package with script task which prints SSRS report. Package runs and everything is just perfect. When I deploy it to production server it doesn't work and I know it's because of the printer I'm sending it to (it's invalid, it's not on the list).
The problem is... SQL Server Agent service account has printers configured, not to mention the printer I'm sending this report to is set as default.
The package is run by another account which has printers configured, correct permissions (for testing purposes this account can do pretty much anything), the fuzzy stuff.
The account running SSIS, in the other hand, can do very little (not even fancy kerberos passing :).
Any suggestions? If you could just point me in the right direction, it would be great.
EDIT
Package runs from SSIS, but doesn't run from SQL Server Agent. We are trying to ad-hoc fix the bug in another companys software (it doesn't create few reports, users don't want to use it, people walking backwards, cats living with dogs), waiting for patch. We can't change the code for obvious reasons, the only solution is to find reports which are not created and create them on our own.