We're using phinx-db for migrations.
I'm trying to find out what happens if a query fails using the execute command. The documentation is not clear about this.
In other words, if I call $this->execute("my sql statement"); and the statement fails, will execute throw an exception? Or will it just fail silently with zero rows updated?
With batch executions any failure is silent, but the documentation does say what happens for a single statement.
Using with PDO it throws a exception.
But I think it may vary depending on which adapter you are using.
Related
I've had a multiple cases where MongoDB failed to properly run a command. First it happened with one of my Python scripts (it's never failed before with the same code). Something broke because the command failed to run properly. I got suspicious and ran it by hand in NoSQLBooster. I got a response with no error. It said acknowledged: true, matchedCount: NaN, and modifiedCount: NaN. I ran it again without changing the command and it worked. Is this something that can happen regularly with MongoDB? Do I need to build in logic to ensure my commands went through properly?
In case it's relevant, here's the command:
db.users.updateMany({}, {"$set": {"f1.f2": 0}})
While it is possible that there is a server bug that caused a command to not be executed, or its outcome to not be reported correctly, it is far more likely that either:
You, or a library you are using, didn't check the execution result and filled in some placeholder values that you think came from the server.
You checked the execution result but didn't do it correctly. The driver is supposed to handle this for you, but you can review server command documentation for the way that that particular command signifies failure. There are quite a few ways that many commands can fail (write concern errors, write errors, etc.).
Updating zero documents is not an error nor is it a failure in the server (you could've had zero documents in the collection to begin with, or none matched the filter you provided).
As far as I know, we can't use start transaction within functions, thus we can't use COMMIT and ROLLBACK in functions.
But how then we ROLLBACK by some if-condition?
How then we can perform a sequence of statements in a specific level of isolation? I mean a situation when an application wants to call a SQL (plpgsql) function and that function really needs to be run in a transaction with a certain isolation level. What to do in such a case?
In which cases then it is really practical to run ROLLBACK? Only when we manually write a script, check something and then ROLLBACK manually if we don't like the result. And in the same case, I see the practicality of savepoints. However, I feel like it is a serious constraint.
If you want to rollback the complete transaction, RAISE an exception.
If you only want to roll back part of your work, start a new block with a BEGIN at the point to which you want to roll back and add an EXCEPTION clause to the block.
Since the transaction is started outside the function, the isolation level already has to be set properly when you are in the function.
You can query
SELECT current_setting('transaction_isolation', TRUE);
and throw an error if the setting is not correct.
is too general or too simple to answer.
You roll back a transaction if you have reached a point in your processing where you want to undo everything you have done so far in the transaction.
Often, that happens implicitly rather than explicitly by throwing an error.
Please see the image.
So here is a flow, wherein the first component executes a database query to find QAR_ID (single row), if it is found then all well. I am trying to put error handling into this. When no rows are found, it directs to tJava_11 which raises an java exception and that gets logged by another tJava component.
The problem I am facing is when it goes to error handling flow, it logs the error and just goes to the post-job section. However, I want Talend to take the OnSubJobOk route so that it continues with other steps instead of directly jumping to post-job section.
I know this is possible using subjobs but I don't want to keep creating 'n' number of subjobs.
Is there any way this can be done in the same job?
You could remove the runif and handle both scenarios in the get_QAR_ID into context component. ie query the database component's NB_LINE after variable, if it's <1 raise the error, else set the value. Your job would then flow to the onSubjobOk.
You can do something like this :
In tJava_1 you do your error logging if no row is returned by your query, and you continue to the next subjob. No need to throw an exception here only to catch it immediately after.
If any row is found, you continue to the next subjob (tJava_2) with an If trigger.
We are encountering the deployment error due to some test classes where batch apex class is called. The error occurring is:
"System.unexpectedException:No more than one executeBatch can be called within a test method."
In our test class, there are insert and update statements which in turn calls the batch apex from a trigger. We have also tried to limit the batch query by using "Test.isRunningTest()" method but we are again facing the same error.
The code works fine in sandbox and the error is coming only at the time of deployment to production.
Also, the test classes causing the error were working fine previously in the production.
Please provide some pointers/solution for the above mentioned error.
Thank you.
I would suggest the best approach would be to ensure the trigger doesn't execute the batch if Test.IsRunningTest() is true, and then test the batch class with it's own test method. I suspect your trigger is fired twice and so batch instances are created and run more than one.
Using a dedicated test method you can execute the batch specifying a limit on the query, and you should use the optional batch size parameter to control the number of calls to execute, i.e. if your limit is 50, but you do this:
Database.executeBatch(myBatchInstance, 25);
It'll still need to call the execute() method twice to cover all the records, and this is where you hit problems like the one you mentioned.
TSQL here. Specifically Server 2008(literally just upgraded)
Concerning stored procedures: Try/Catch
I was trying to make a list of cases when a Select Statement will throw an exception. The ones I can think of are syntax related(includes null variables) and divide by zero. I'm only guessing there are just a whole boat load of them for Insert/Alter and Create/Truncate.
If you happen to know of a good source link, that would be great.
This question came up when I was reading this exhaustive blog post about error handling for SQL server. It's titled for SQL Server 2000, but I think most of it still applies.
edit
Sorry, I meant to link this earlier. . .
http://msdn.microsoft.com/en-us/library/aa175920(v=sql.80).aspx
Outside for compile ("didnt' run") errors, you have at least these runtime errors
arithmetic errors
These change based on various SET statement
Example: get sql server to warn about truncation / rounding
overflow errors
example: one of the rows overflows smallint in some calculation
CAST errors
eg you try ISNUMERIC in a WHERE or CASE and try to cast 'bob^' or 1.23 to int
See Why use Select Top 100 Percent?
However, you'd always want to use TRY/CATCH though, surely...?
Adding to gbn's post, you can also get locking errors like lock wait timeouts and deadlocks.
If you are referencing #Temp tables, you can get "Invalid object name '#Temp'" errors, because these are unbound until the statement executes.
If you are in READ UNCOMMITTED or WITH (NOLOCK), you can get error: 601 - "Could not continue scan with NOLOCK due to data movement."
If your code runs .NET code, you would probably get exceptions from there.
If your code selects from a remote server, you could a whole different set of errors about connections.