In SSIS, I am running a stored procedure in an ExecuteSQL Task. It is erroring out with:
Executing the query "EXEC [dbo].[mySP]" failed with the following error: "The Microsoft Distributed Transaction Coordinator (MS DTC) has cancelled the distributed transaction.Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
I don't have any parameters or resultset.
I was getting this same error. I had a Master Package that was executing multiple individual packages. I thought it was a permissions issue of some sort at first because those 2 packages were the only ones touching a different schema. Wrong. Turns out those 2 packages were the only ones in the entire Master Package that weren't serial in nature (were running concurrently). After I made one package run and complete before the other everything started working.
Related
I am trying to execute oracle stored procedure from my application and connecting ORACLE database. I noticed, same connections call get passed and some connection throwing exception as below:
ORA-04068: existing state of packages has been discarded
ORA-04061: existing state of package body "USER.PKG_MY_PACKAGE" has been invalidated
ORA-04065: not executed, altered or dropped package body "USER.PKG_MY_PACKAGE"
ORA-06508: PL/SQL: could not find program being called: "USER.PKG_MY_PACKAGE"
ORA-06512: at line 34
I referred some stack overflow post and we can fix in DB side. But DB side I don't have access to fix this issue(i.e. production) is there any way to fix from application side. I am using JDBI-Datasource-connection pooling in my java code. If I restart my lower environments and works fine. But, I can't restart the production environment each and every time. Please let me know, how to fix this issue from my application side.
I found similar questions online but in the context of java code. I am facing this error while running cypher from the neo4j browser. I have to run the same cypher several time, until accidently it gets executed. Rarely query runs in 4-5 attempts, in most cases I have to try 20+ times. This is how it looks in the browser:
The error continues after running :server connect too. How do I fix this once forever. I am fed up rerunning cypher...
Added: I am using Neo4j CE 3.0.4. Can it be due the fact that I might be using databases created in old versions?
Currently running TFS 2013 Update 4 (12.0.31101.0 (Tfs2013.Update4))
We're trying to upgrade to TFS 2015 and it fails with the error
[Error #18:03:16.990] TF255430: The database Tfs_DefaultCollection was partially upgraded during a failed upgrade. You must restore your data from a backup to its original state to continue.
The above database is for the Default Team Project Collection and we don't use it. That collection is offline, and has been for many months. There is nothing in that collection and we have no need to keep it. We just need to remove it as it's blocking our upgrade.
Looking in the Project collection status, I can see that there is an ApplyPatch job that failed. Have tried re-running the job but it continues to return the following failure messages.
[18:45:10.700] Database: Tfs_DefaultCollection, Sql Instance: MDCPTFS02
[18:45:10.967] [Error] TF400744: An error occurred while executing the following script: CollectionFrameworkDev10ToDev11CTP1.sql. Failed batch starts on the line 336. Statement line: 8. Script line: 343. Error: 1750 Could not create constraint. See previous errors.
[18:45:10.990] Microsoft.TeamFoundation.Framework.Server.TeamFoundationServicingException: TF400744: An error occurred while executing the following script: CollectionFrameworkDev10ToDev11CTP1.sql. Failed batch starts on the line 336. Statement line: 8. Script line: 343. Error: 1750 Could not create constraint. See previous errors.
Hope someone can provide some ideas on working around this issue.
Cheers
Phil
If you have the backup database, the simplest and safe way is following the instructions above as “You must restore your data from a backup to its original state to continue”. Restored the collection, re-ran the update and all should works well. Finally, you just need to delete the redundancy collection.
You can also choose to Detach the Collection first just as comment suggested and try the update again.
Update
If you really don't need that project collection. You can try to delete it through command line.
On TFS server, open Administrative Command Prompt and change to TFS Tools Directory.
%programfiles%\microsoft team foundation server[versionnumber]\tools
Type the command:
TFSConfig Collection /delete /collectionName:[COLLECTION NAME]
Details please refer this blog: how to delete a Team Project Collection
Then delete the collection database Open SQL Server Management Studio, connect to the instance of the SQL Server Database Engine that hosts the collection database, and expand the instance.
Highlight the name of the collection database (by default, TFS_CollectionName), and then delete the database. and delete the SharePoint site collection that supported the deleted collection.(If you have).
I have a Windows service written in VB.NET 2.0 which connects to an IBM AS/400 server. Queries work fine, but when I try to do something like deleting a spool file, I get errors. For example:
CPYSPLF FILE(PO630A) TOFILE(MPLCDATPAR/PO630APF) JOB(083064/ARUSER/POASYNCMON) SPLNBR(80) MBROPT(*REPLACE)
Running this command with ExecuteNonQuery yields:
CPF3342 - Job not found 083064/ARUSER/POASYNCMON
However, if I run that same command locally in AS/400, it works just fine. We already checked permissions. What else could be causing the command to fail this way? How can I get more information about the error, or go about troubleshooting this?
EDIT: This problem (and a lot of other ones) appeared when we migrated our server (where the .NET service runs) from Windows Server 2003 to Windows Server 2008.
How can I get more information about the error, or go about troubleshooting this?
The first thing is to verify that the IBM AS/400 server [what OS Version Release and Modification level, Technical Refresh (TR) level (if instead IBM i), Cumulative PTF level were all omitted.?.?] used for the connection is the same server used to perform the command-line invocation; i.e. on the server where the command-line invocation will be made to verify the command is functional, find the active server job in which the CPF3342 is still visible in the log.
The second thing to do is to get the spooled joblog showing the full details of the CPF3342 [and possibly any preceding message(s) that might be related]. If for example the message is not actually that message or is not sent by the expected program QSPCPYF, then immediately the direction of investigation probably would change. What is shown is apparently what is presented at the client, not what came from the server joblog; the USEnglish formatting I believe is "Job &5/&4/&3 not found." for which the formatting "CPF3342 - Job not found &5/&4/&3" is suspect.
To ensure the most appropriate comparison to the request made from the client:
• the local user that is signed-on to perform the same request should be the same user as the Current User of the active job found to be servicing the client request
• the local user should establish the same System Library List as the active job found to be servicing the client request
If such an incident recurs or even if the same incident persists, then verify the once again the re-create is still possible using the same interface [i.e. the condition\failure persists] and again verify the command-line request is successful [i.e. the circumvention is confirmed, that the same request is possible to be performed at the command-line]; and according to my earlier comment, first ensuring the same server by finding the active job that logs the CPF3342. Immediately afterward:
• Collect a job trace for the Copy Spooled File (CPYSPLF) request; for the failing case, review for any exception\interrupt conditions [with or without a message as accompanying trace data] that precede the program flow for the issuance of the msg CPF3342.
• Review the audit log for any T-AF or anything odd\unexpected at very close to the time of the failing request; expansive auditing should have been established since before the connection to the server.
• Contrast those data collections of the failing case with the same data taken from the successful processing.
Although the symptom [as lightly described, without the full joblog] the possibility of command-exits seems remote, the trace would reveal if the command in either scenario were intercepted by the Command Exit points; these can be reviewed separately [rather than looking in the trace] for any Exit Program, using the Work With Registration Information (WRKREGINF) to review any QIBM_QCA* entries in the repository for what exit programs might impact the CL Command request. But IIRC the trace-data shows which command was invoked, so the trace would also reveal if the unqualified command requests resolved to different *CMD objects.
For one of our gerrit projects, while navigating the file differences we get this error:
Application Error
Intraline difference not available due to server error
[Continue]
It doesn't happen for all projects, currently we've detected the error on only one project.
I looked on Google and on the gerrit documentation. Found a reference on their source code, but don't know what causes it and how it can be resolved.
The web page with the error contains a "Continue" button. Once clicked it will take you to the file you selected, but the error is annoying.
Do you know how to fix this?
That is caused while cache the intraline difference of one file, when compared between two commits. The default timeout value is 5 seconds. If the file is huge, and computation takes longer than the timeout, the worker thread is terminated, an error message is shown, and no intraline difference is displayed for the file pair.
A solution could fix this.
Add config in gerrit.conf.
[cache "diff_intraline"]
timeout = 15000 ms # Or other time length as you want.
restart Gerrit service
run SSH command "gerrit flush-caches", using a user with ViewCaches global capability.
ssh -p port userxxx#host gerrit flush-caches
Then it would work.
Cause of the error:
It is a result of Gerrit taking too long to diff the file, and marking the diff in one of its caches as non-available.
The relevant error log is here:
[2012-06-08 11:14:08,547] WARN com.google.gerrit.server.patch.IntraLineLoader : 5000 ms timeout reached for IntraLineDiff in project xxxxxxx on commit 354dd67ad54578cf801d8cda64a4ae8484ebb0b7 for path xxxxxxx.java comparing bf9fbc21520af7bfd0841c8b9f955ca6e215b059..f6b9c7992c12cfdca253acd033966f98f70f3543. Killing IntraLineDiff-6