anyone know something about this error?
ORA-02048: attempt to begin distributed transaction without logging on
ORA-02063: preceding line from ..dblink
It occurs when I invoke since Java a PL/SQL Package that contains dblinks to access to other database for insert data. The dblink works good with other clauses, but not in this Package.
If I invoke this PL/SQL Package since TOAD, it works good.
I'm trying to reproduce this error, and I see this error arises from a pattern:
When I click the button which makes the PL run, the log shows me an error "ora-02292 integrity constraint child record found", and the next time I click the button, appears the error "ORA-02048", it is like the first error did lose the connection with remote database.
Thanks in advance
Without seeing a minimal testcase that demonstrates the problem, it's impossible to say.
However, looking up the error message:
-bash-4.1$ oerr ora 2048
02048, 00000, "attempt to begin distributed transaction without logging on"
// *Cause: client program must issue a distributed transaction login.
// *Action: contact support.
So, I'd recommend contacting Oracle support and opening an SR. But, the first thing they're likely to ask for is a working test case that demonstrates the problem.
The problem was thatI have different procedures, like that:
procedure1 -> (call) -> procedure 2 -> (call) -> procedure3
In procedure3 I have a clausure with dblink that insert into a remote table.
Procedure1 catchs the exceptions that may occur in procedure 2 and procedure3.
The problem is when an exception is throw in procedure3. In this case the rollback placed in the exception catch of procedure1, should finish the transaction, but it isn't working as I expected. The transaction is this case remains open and the second time in the procedure executions, oracle shows me the ORA-02048 error.
The solution was moving the exception catch into procedure3.
Related
I am having a trigger issue resulting in the following error being returned to the updating application (Datalinx WHM is Updating a Sage1000 table):
'A trigger returned a resultset and/or was running with SET NOCOUNT OFF while another outstanding result set was active'
The offending trigger is one of 7 on the table and all currently have SET NOCOUNT ON; set. Disabling and re-enabling the triggers one by one has not turned up anything to conclusively identify which trigger is causing the issue which makes me wonder whether it is the volume of triggers and the time it takes for them to fire causing the problem (I don't know enough to know whether that is feasible?).
Having got nowhere with with the above so far i have turned to SQL trace to try and narrow it down, which leads me to the following question:
I have enabled events for Stored procedures (SP:StmtStarting - SP:StmtCompleted) and errors amongst others (please see below for full list event settings)so i can see the table update and the subsequent error being returned (i Cant attache the trace or an image as a newbie) but it doesn't show the trigger names firing so i know which one is at fault. Are there other events i can select which may help?
Thanks in advance
Trace events selected:
Cursors: CursorClose, CursorExecute, CursorOpen, CursorPrepare
Errors and warnings: Attention, ErrorLog, EventLog, User Error Message
Stored procedures: RPC:Completed, SP:Completed, SP:Starting, SP:StmtCompleted, SP:StmtStarting
TSQL: Exec Prepared SQL, Prepare SQL, SQL:StmtCompleted, SQL:StmtStarting
Recently we are getting the "procedure has not been executed or has no result" across our PowerBuilder Application. This error is random, but is triggered in places where we have calls to Stored Procedures or some dynamic SQL queries. After each call to the procedure, we close the procedure in powerbuilder. We need to know the cause of this error because this is not caused on our environment, only in the production environment. Even better would be a way to resolve this issue.
The database is SQL Server. The exact error details are as follows:
ERROR Code: -1
ERROR Text: procedure has not been executed or has no result
Row Count: 0
Terminating application-
I am not even sure if the error is from Database or from Powerbuilder itself. The code is a simple call to a procedure. Here is some code that is causing this issue:
DECLARE setRequestStatus PROCEDURE FOR sRequestStatus
// parameters here
USING SQLCA;
EXECUTE setRequestStatus;
FETCH setRequestStatus into :statusCode;
CLOSE sp_PfW_ERxSetRequestStatus;
RETURN statusCode
Do reply if you need any more details.
Thanks in advance!
According to this post, the problem is an exception being raised by your stored procedure-- possibly due to transaction size. Follow the link to get more details.
We have a .NET application (VB / VS2010) and are calling many stored procedures on a SQL Server 2008 for database queries. We also have quite a few update/insert/delete triggers that are executed automatically once these stored procedures modify the database tables.
There are quite often situations when a stored procedure is called and it seems to perform ok as no error is raised and the .NET app continues as usual. However if I then look under the covers and perform the stored procedure call manually via SQL Server Client I see that a trigger that's executed right after the stored procedure fails, thus rolling back all changes.
So my question is: what's the best way to detect and pass through errors in our .NET --> stored procedure --> trigger scenario to know for sure in the .NET app that everything succeeded or not in case of an error?
Many thanks in advance,
Steve
Update: I am at home now and away from my desk (and the code base) for the weekend, so won't have a chance to check the very details of the stored procedures. Thanks so much for the answers given so far. I can have a look at the code again next week.
But in the meantime...
One question was about the version of MS SQL Server: it's 2008.
From what I know out of the top of my head we are calling the stored procedures (at least those that don't read data and "just" update, delete or insert data) in this manner:
Using connection As New SqlConnection("connectionString")
Dim command As New SqlCommand("EXEC STORED_PROCEDUR_ENAME), connection)
command.Connection.Open()
command.ExecuteNonQuery()
End Using
I think the assumption behind the code above is the expectation that if something fails within the stored procedure or a related trigger, that
command.ExecuteNonQuery()
would then fail. That might be my first problem, i.e. will I have to alter this code?
One question below was if I use ExecuteDataReader, so the answer is no, at least not so far...
I'll comment on the SQL specific questions and suggestions below.
I actually had the same issue today,
to solve it i used an output #msg and placed it after each function in the sproc.
SET #msg = 'Test print 1'
each section i added one so i know what ever the last number printed was where the sproc failed. I then went to the table where the trigger was failing and adjusted it until it printed the last number and passed.
You should check ##error after each statement, and return the error if one exists.
Here's a good article for you. Check out the section "Why is My Error Not Raised". It describes a scenario that could be your problem.
http://www.sommarskog.se/error-handling-II.html
You might also want to try turning XACT_ABORT on, so stored procedures would fail for most errors.
EDIT: Here's another link that might help explain this.
http://www.novicksoftware.com/tipsandtricks/tips-erorr-handling-in-a-stored-procedure.htm
You can either return an error from your procedure if you check ##error and find it != 0, or you can use RAISERROR, which will definitely result in an exception in calling code.
http://msdn.microsoft.com/en-us/library/ms178592.aspx
as you mention that you are using sql server 2008. this gives capacity to use try.. catch. here is the article.
http://msdn.microsoft.com/en-us/library/ms175976.aspx
Also look at this forum.
http://social.msdn.microsoft.com/Forums/eu/transactsql/thread/03eae70e-d478-44a7-90f3-8e1d27d9f22e
i think try..catch will do the job. also in .net side i would use following code.
try
{
// your stored procedure execution code.
}
Catch (sqlexception e)
{
// do something with sql exception.
}
try this scenario see if that solves your issue.
I have an issue where I call a stored procedure from a linked server and it times out. However I have no good way of catching this. Though it occurs rarely I am wondering if there is any way to catch this particular warning:
OLE DB provider "SQLNCLI10" for linked server "serverName" returned message "Query timeout expired".
Unfortunatly warnings aren't caught by try/catch and MS does have an open issue that this should be an error: http://connect.microsoft.com/SQLServer/feedback/details/337043/no-error-raised-when-a-remote-procedure-times-out
I don't want to increase the timeout property, and I know I can do something like:
Declare #ret int
select #ret = 4417
Exec #ret=Server.DB.dbo.RemoteSP
If #ret is null afterwards it means the call failed, however it does not tell me exactly what the cause was. Is there anyway to essentially catch that warning? What are the best practices in for remote procedure calls error handling?
As of 2019 there is still no way to properly catch SQL Server remote timeout errors.
It applies both to remote SP calls and constructs like execute ('select 1') at REMOTESQLSERVER.
As per comment from N.Nelu:
Microsoft docs state under "Errors Unaffected by a TRY...CATCH Construct".
Errors Unaffected by a TRY...CATCH Construct
TRY...CATCH constructs do not trap the following conditions:
Warnings or informational messages that have a severity of 10 or
lower.
Errors that have a severity of 20 or higher that stop the SQL Server Database Engine task processing for the session. If an error
occurs that has severity of 20 or higher and the database connection
is not disrupted, TRY...CATCH will handle the error.
Attentions, such as client-interrupt requests or broken client connections.
When the session is ended by a system administrator by using the KILL statement.
Connect link you have provided is dead but you still can vote to fix this feature here. See also this excellent article on SQL Error handling under 4.3 Query Timeout on Linked Servers.
I am running a stored procedure in SQL Server 2008 inside a try/catch. The stored procedure and the stored procs it calls raise a few errors but in the try/catch you only get the last error from the stored procedure that you are running.
Is there a way/trick to be able to somehow catch ALL the errors generated by child stored proc calls while running a particular stored procedure? (assume that you have no access to any stored procedures so you can't modify where they can write the error, i.e. you can't just change all the stored procedures to stop raising errors and instead write them to some table and in your catch read from that table)
Here is a good resource for how to deal with error handling in SQL Server.
http://www.sqlservercentral.com/articles/Development/anerrorhandlingtemplatefor2005/2295/
However, some of the methods require that you have the ability to change the code in order to capture the errors. There is really no way of getting around this. You can't just ignore the error, keep processing, and then come around later to deal with the error. In most, if not all, languages, exceptions have to be dealt with at the time the exception was raised. T-SQL is no different.
I personally use a stored procedure to log any error whenever it occurs. Here is what I use:
CREATE PROCEDURE [dbo].[Error_Handler]
#returnMessage bit = 'False'
WITH EXEC AS CALLER
AS
BEGIN
INSERT INTO Errors (Number,Severity,State,[Procedure],Line,[Message])
VALUES (
ERROR_NUMBER(),
ERROR_SEVERITY(),
ERROR_STATE(),
isnull(ERROR_PROCEDURE(),'Ad-Hoc Query'),
isnull(ERROR_LINE(),0),
ERROR_MESSAGE())
IF(#returnMessage = 'True')
BEGIN
select Number,Severity,State,[Procedure],Line,[Message]
from Errors
where ErrorID = scope_identity()
END
END
If you have stored procs that are raising more than one error, they need to be replaced no matter what. You probably have data integrity errors in your database. That is a critical, "everything needs to stop right now until this is fixed" kind of issue. If you can't replace them and they were incorrectly written to allow processing to continue when an error was reached, then I know of no way to find the errors. Errors are not recorded unless you tell them to be recorded. If the stored procs belong to a product you bought from another vendor and that's why you can't change them, your best bet is to change to a vendor that actually understands how to program database code because there is no salvaging a product written that badly.
You wouldn't have a Java or c# methods raising error after error. Why do you expect SQL to allow this? An exception is an exception
If the DB Engine is throwing errors then you have problems.
What I've done before is to separate testing and checking code: find out what is wronf first and throw one exception If no errors, do your writes.