I have a Neo4j transaction that is composed from several cypher queries.
for idempotency sake, i'd like to include a validation query that will fail the transaction if needed.
any idea how can i do that?
i was looking how to return an error or throw exception but it doesn't seem so popular as i cant find anything about it
whats the best practice that is recommended here?
You could use apoc.util.validate to throw an error from inside cypher.
Example:
CALL apoc.util.validate(true, "MY ERROR MESSAGE")
Related
I was testing possible issues with a query when the connection is lost or timed out. To do the test, I run a query with a fresh connection, and just seconds after I kill the program or disconnect the network. Then I check the impact of the query.
I believe that if a query, not within the explicit transaction fails for any reason, will roll back the effect. Of course, this makes sense for operations like DELETE, INSERT, UPDATE or DDL statements too. Implicit Transaction is OFF in the db.
My theory held true except when I ran a SELECT-INTO statement. Sample query that I tried -
SELECT * INTO test_table FROM audit
It failed due to Socket read timeout but later I found that even though there are no records inserted, the new table test_table was created as empty.
After browsing the docs for a while, according to official documentation, it's expected behavior. That's understandable. But the problem for me is that I can't really retry this query execution as the table already exists.
I guess to fix this I need to use the explicit transaction around such statements.
To help me with the feature - Am I going the right way? And are there any other SQL statements that can cause similar behavior?
Thanks in advance.
Edit:
Since I got suggestions on how to fix this, I am wondering now if there are any other SQL statements that can cause similar behavior.
Error:Apex trigger AccountAddressTrigger caused an unexpected exception, contact your administrator: AccountAddressTrigger: execution of AfterUpdate caused by: System.FinalException: Record is read-only: Trigger.AccountAddressTrigger: line 6, column 1
while solving Create an Apex trigger for Account that matches Shipping Address Postal Code with Billing Address Postal Code based on a custom field.
I got the above mentioned error
I had write correct logic but still get the error.
Your question is really poor, post the code you've writte so far and/or link to that challenge (what is it, a Trailhead task? Homework? Job interview?)
My guess is that your trigger should operate as "before insert, before update", not "after". Before's are for all kinds of validations and field prepopulation and one of notable features is that you don't need to explicitly write update myrecords; - you get save to database for free. After's are more for side effects like creating related records, anything that makes sense only after you generated record's Id.
I have a job that runs clean up queries from a table. There's a cursor that rolls through the queries, if one fails there's a try catch that will get the error message from the query on the table and database. Which puts that information in an email with sp_send_dbemail.
I am wondering if it is possible to change the catch block after the query runs to look for transactions that were successful. Then get the updated rows, or maybe just IDs for the rows, and put those IDs in an email?
Or would it be easier to just look for rows to update in the query when the job is running it to create an email after the updates happen?
It sounds like the output clause might be useful here. You can find many examples of usage by searching. In short, you add the output clause to each "cleaning" statement and capture the information you need. Yes - each statement. I am doubtful about your goal - but that is a different issue.
And btw - the catch block runs when an error occurs. It does not make much sense to use the catch block to look for the effects of successful statements. In the catch block you know that the most recently executed statement in your try block failed. And of course, if every statement is successful the catch block never executes.
We are currently on SQL 2005 at work and I am migrating an old Foxpro system to new web application backed by SQL Server. I am using TRY CATCH in T-SQL for transaction processing and it seems to be working very well. One of the other programmers at work was worried about this as he said he had heard of issues where the catch phrase did not always catch the error. I have beat the sproc to death and cannot get it to fail (miss a catch) and the only issues I have found searching around the net is that it will not return the correct error number for error numbers < 5000. Has anyone experienced any other issues with TRY CATCH in T-SQL - especially if it misses a catch? Thanks any input you may wish to provide.
TRY ... CATCH doesn't catch every possible error but the ones not caught are well documented in BOL 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.
The following types of errors are not
handled by a CATCH block when they
occur at the same level of execution
as the TRY…CATCH construct:
Compile errors, such as syntax errors, that prevent a batch from
running.
Errors that occur during statement-level recompilation, such as
object name resolution errors that
occur after compilation because of
deferred name resolution.
These errors are returned to the level
that ran the batch, stored procedure,
or trigger.
There was one case in my experience when TRY...CATCH block didn't catch the error. There was error connected with collation:
Cannot resolve the collation conflict between "Latin1_General_CI_AS" and "Latin1_General_CI_AI" in the equal to operation.
Maybe this error correspond one of the error type documented in BOL.
Errors that occur during statement-level recompilation, such as object
name resolution errors that occur after compilation because of
deferred name resolution.
TRY ... CATCH will fail to catch an error if you pass a "bad" search term to CONTAINSTABLE
For example:
DECLARE #WordList VARCHAR(800)
SET #WordList = 'crap"s'
CON
TAINSTABLE(table, *, #WordList)
The CONTAINSTABLE will give you a "syntax error", and any surrounding TRY ... CATCH does not catch this.
This is particularly nasty because the error is caused by data, not by a "real" syntax error in your code.
I'm working in SQL Server 2008. I built a big sql statement that had a try/catch. I tested it by renaming a table (in dev). The statement blew up and didn't catch the error. Try/catch in SQL Server is weak, but better than nothing. Here's a piece of my code. I can't put any more in because of my company's restrictions.
COMMIT TRAN T1;
END TRY
BEGIN CATCH
-- Save the error.
SET #ErrorNumber = ERROR_NUMBER();
SET #ErrorMessage = ERROR_MESSAGE();
SET #ErrorLine = ERROR_LINE();
-- Put GSR.dbo.BlahBlahTable back the way it was.
ROLLBACK TRAN T1;
END CATCH
-- Output a possible error message. Knowing what line the error happened at really helps with debugging.
SELECT #ErrorNumber as ErrorNumber,#ErrorMessage as ErrorMessage,#ErrorLine AS LineNumber;
I have never hit a situation where TRY...CATCH... failed. Neiteher, probably, have many of the people who read this question. This, alas, only means that if there is such a SQL bug, then we haven't seen it. The thing is, that's a pretty big "if". Believe it or not, Microsoft does put some effort into making their core software products pretty solid, and TRY...CATCH... is hardly a new concept. A quick example: In SQL 2005, I encountered a solid, demonstrable, and replicable bug while working out then-new table partitioning--which bug that had already been fixed by a patch. And TRY...CATCH... gets used a bit more frequently than table partitioning.
I'd say the burden of proof falls on your co-worker. If he "heard it somewhere", then he should try and back it up with some kind of evidence. The internet is full of proof for the old saying "just because everyone says its so, doesn't mean they're right".
I've been sorting out the whole nested transaction thing in SQL server, and I've gleamed these nuggets of understanding of behavior of nested trans':
When nesting transactions, only the
outermost commit will actually
commit.
"Commit Trans txn_name", when nested
, will always apply to the innermost
transaction, even if txn_name refers
to an outer transaction.
"ROLLBACK TRAN" (no name) , even in
an inner transaction, will rollback
all transactions.
"ROLLBACK TRAN txn_name" - txn_name must
refer to the outermost txn name.
If not, it will fail.
Given these , is there any benefit of naming transactions? You cannot use it to target a specific tranasction, either for commit or rollback.
Is it only for code commenting purposes?
Thanks,
Yoni
Effectively it's just a programmers aide memoire. If you're dealing with a Tx that has a number of inner transactions, giving each meaningful names can help you make sure that the tranactions are appropriately nested and may catch logic errors.
You can have procedures rollback only their own work on error, allowing the caller to decide wether to abandon the entire transaction or recover and try an alternate path. See Exception handling and nested transactions for a procedure template that allows this atomic behavior.
The idea is to roll back part of your work, like a nested transaction. Does not always work as intended.
Stored procedures using old-style error handling and savepoints may not work as intended when they are used together with TRY … CATCH blocks: Avoid mixing old and new styles of error handling.
Already discussed here ##ERROR and/or TRY - CATCH