I'm calling a java stored procedure from oracle. After i called execute() method it is never coming out of SP execution and locking the tables. But after i stop the server, the records are getting inserted into tables. Any one face similar issue?
Got the solution. Before calling the SP, i'm doing many insert and update statements and they are locking 5 to 6 tables. I committed the transaction before calling the SP and after that my SP is running fine.
Related
I would like your point of view about writing Oracle PL/SQL stored procedures and calling them in a Zend framework 3 controller.
If in my PL/SQL strored procedure I have a commit at the end of my procedure, and I use it in a controller with in proper transaction code, if there is an exception in my PHP code after calling the stored procedure, does the commit set in the database ? even if in my PHP code the rollback function is called ?
Once your PL/SQL procedure issues COMMIT, that's it. Any subsequent rollback won't have any influence on what you already committed.
I need to quickly execute stored procedure which updates table with data from different data source in SQL Server. Is it possible to do it with EF7, I have tried FromSql, but this seems to only works with the mapped entities.
It doesn't need to return anything, just execute.
Is there any other method than using SQLConnection, or SQL job running every 10 minutes on the server?
I think you can use DbContext.Database and ExecuteSqlCommand to execute your stored procedure.
_db.Database.ExecuteSqlCommand("EXEC mySp");
I'm working with SQLite for my Android application and after some research I figured out how to do multiple insert transactions using the UNION statement.
But this is quite inefficient. From what I see at http://www.sqlite.org/speed.html, and in a lot of other forums, I can speed up the process using the BEGIN - COMMIT statements. But when I use them I get this error:
Cannot start a transaction within a transaction.
Why? What is the most efficient way of doing multiple insert?
Which JDBC driver are you using? Is there only one that's built into the Android distribution?
The problem is most likely with java.sql.Connection#setAutoCommit(). If the connection already has auto-commit enabled—which you can check with Connection#getAutoCommit()—then your JDBC driver is already issuing the SQL commands to start a transaction before your manual attempt to do, which renders your manual command redundant and invalid.
If you're looking to control transaction extent, you need to disable auto-commit mode for the Connection by calling
connection.setAutoCommit(false);
and then later, after your individual DML statements have all been issued, either commit or roll back the active transaction via Connection#commit() or Connection#rollback().
I have noticed that some JDBC drivers have a hard time coordinating auto-commit mode with PreparedStatement's batch-related methods. In particular, the Xerial JDBC driver and the Zentus driver on which it's based both fight against a user controlling the auto-commit mode with batch statement execution.
I have an issue in calling oracle stored procedures(oracle xmltype as input parameter) in ASP.NET 2.0 using ODP.NET (Oracle.DataAccess assembly version 9.2.0.700).the web page freezes during processing on executenonquery.
Executenonquery is not firing any command on database. i have implemented some tracing logic and found that no request is made to database procedure and web page is freezes.
I just had an issue calling a stored procedure using inputoutput parameters that was freezing on ExecuteNonQuery. My code looked correct. I had Oracle SQL Developer opened that had some non commited transactions. I disconnected from the database. The dba killed all of my processes. I ran the same code again and it worked perfectly.
We noticed in a SQL Server Profiler trace that this proc is being called:
sp_procedure_params_managed
Each call has 350+ reads in the trace!
We are using Microsoft.Practices.EnterpriseLibrary.Data in an ASP.NET front end.
How can we eliminate these stored procedure calls? We are not explicitly calling it in code.
I'm running Sql Server 2005 and Enterprise library 3.1.0.0.
sp_procedure_params_managed is used determine the stored procedure parameters. I guess the Microsoft.Practices.EnterpriseLibrary.Data uses it to determine what the parameters are for the stored procedure call. It will probably cache the results to prevent extra overhead.