It looks like you're overthinking your merge statement. The error is telling you that it's expecting an equality operator instead of an IN. For example, AND MERGE_TARGET.A IN ( should be AND MERGE_TARGET.A =. Then you need to replace the subquery with a column name. Looking at the below section of code further, I see you're trying to find if merge_target (which is table_a) has a value within a subquery that returns tableA.A. Further the subquery joins TableA to TableB on this same column (A), where TableB is then also equal to the current row in MERGE_USING (TableB). The net effect is no different than AND MERGE_TARGET.A = MERGE_USING.A AND MERGE_TARGET.A IN ( SELECT MYTABLE_A.A FROM MYTABLE_A INNER JOIN MYTABLE_B ON MYTABLE_B.A = MYTABLE_A.A WHERE MERGE_USING.B = MYTABLE_B.B ) When thinking of a MERGE, just think of it as a SIMPLE JOIN statement. INTO is TABLE 1 of the JOIN, USING is TABLE 2 of the JOIN, and ON is what JOINS them. Now that you have your condition, what do you do when it matches or does not match. You also have an unneeded joins inside of your USING clause. Table_A is already your target. If we remove the join and move the WHERE conditions to the the ON portion of the MERGE, we'll end up with something like this... MERGE INTO MYTABLE_A USING MYTABLE_B /* Below is your JOIN/WHERE condition. JOIN source and target here on the columns that need to match */ ON MYTABLE_B.A = MYTABLE_A.A AND MYTABLE_B.C = MYTABLE_A.C AND MYTABLE_A.LOGIC = 1 AND MYTABLE_A.OTHERLOGIC = 1 AND MYTABLE_B.LOGIC = 2 WHEN MATCHED THEN UPDATE SET MYTABLE_A.D = MYTABLE_B.D, MYTABLE_A.E = MYTABLE_B.E

(I don't have sufficient reputation to comment yet) Have you compiled the package spec? And what happen when you compile the views? alter package DBMS_AUDIT_UTIL compile; alter view FGA_AUDIT_TRAIL VIEW compile;

MariaDB-10.5.13 has this https://github.com/MariaDB/server/commit/f03fee06b0 that potentially improved the error message. You could try https://mariadb.com/kb/en/check-table/ on the underlying tables though I suspect if there was errors here they would have shown up in the mariadb error log. To test if 10.5.13 is released has fixed this error (unlikely, can't see anything in the https://mariadb.com/kb/en/mariadb-10513-release-notes/ or change log), or provides a more detailed error, you can run that mariadb:10.5.13 container on your same data directory and execute the same query. If you want to check if the soon to be released 10.5.14 release fixes it, you can use the quay.io/mariadb-foundation/mariadb-devel:10.5 image (ref https://mariadb.org/new-service-quay-io-mariadb-foundation-mariadb-devel/ ). Otherwise I suggest searching and/or https://jira.mariadb.org/ including your configuration and table/view structures potentially with explain {query}. If you really want to help out the MariaDB developers, obtain a backtrace with the https://mariadb.org/mariadb-debug-container/ , set a breakpoint with b mysql_errno_to_sqlstate before r, and obtain the full stacktrace where it occurred.

Only events that are send to the application event log of windows can be used for alerting. This can be done with RAISERROR when WITH LOG is specified see https://docs.microsoft.com/en-us/sql/t-sql/language-elements/raiserror-transact-sql?view=sql-server-ver15#:%7E:text=Description-,LOG,-Logs%20the%20error The following code will generate 2 errors, the second one will be send to event log, the first one not. The second one will trigger your alert, the first one not. RAISERROR('Test for dba.stackexchange 1', 16, 1); RAISERROR('Test for dba.stackexchange 2', 16, 1) WITH LOG; Operating system errors (like access is denied, not enough disk space, ...) are logged to the application event log of windows. Divide by zero is not logged to the application event log of windows. This are the messages that triggers the alert for the backup error. SELECT * FROM sys.messages WHERE 1=1 AND is_event_logged = 1 AND Severity = 16 AND message_id IN (3041,18204) AND language_id = 1033 message_id language_id severity is_event_logged text 3041 1033 16 1 BACKUP failed to complete the command %.*ls. Check the backup application log for detailed messages. 18204 1033 16 1 %s: Backup device '%s' failed to %s. Operating system error %s. Which are different messages that are displayed in SSMS, and in your query. You can test this on your alert by providing a filter. The message_id is visible in event log: How to trigger the alert You can wrap your code like this and rethrow the exception WITH LOG and then your alert should work. DECLARE @ErrorMessage NVARCHAR(4000), @ErrorSeverity INT, @ErrorState INT; BEGIN TRY SELECT 1/0; END TRY BEGIN CATCH SELECT @ErrorMessage = ERROR_MESSAGE(), @ErrorSeverity = ERROR_SEVERITY(), @ErrorState = ERROR_STATE(); RAISERROR(@ErrorMessage, @ErrorSeverity, @ErrorState) WITH LOG; END CATCH; Please also read the https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-add-alert-transact-sql?view=sql-server-ver15#remarks of the SQL server alerts.

CREATE TRIGGER IF NOT EXISTS log_logout AFTER UPDATE OF logout ON session_log BEGIN UPDATE session_log SET duration = (JULIANDAY(logout) - JULIANDAY(login)) * 24 * 60 --minutes WHERE id IN (SELECT id FROM session_log ORDER BY id DESC LIMIT 1); END;

In general, if a problem occurs we expect to know the following: Problem. Reason. What to do. This will help to decide what to use. Your examples: Problem: Payment couldn't be completed. Reason: No response from (the) bank. What to do: Use another card or try again later. Problem: Payment couldn't be completed. Reason: Transaction (was) rejected by the bank. What to do: Check if you (have) entered (the) right CVV code.

How do you make sure that your code is working at all? Usually, that's done with automated tests, and the UI is no different in this regard. Tests like these can even be written before your feature is finished (as https://en.wikipedia.org/wiki/Test-driven_development requires). Having tests also means you'll know if it breaks later down the line. In my stack, this is done with https://laravel.com/docs/8.x/testing and https://laravel.com/docs/8.x/dusk . The latter uses a browser like a real user, so interactions that rely on Javascript can be tested.

This sounds something like a find and replace all. If the system finds one discrepancy, It's possible to have communication that points this out: "[this] choice is not valid, only 'B, C, D' can be accepted". Or simply 'invalid selection, chose a valid option'. Then follow up with a way to apply this fix to the remainder of the form. It could be as soon as the user changes the input from invalid to valid, there is a new element that says 'apply to all instances' or 'X instances found, apply to all'. There are various ways you could communicate this in a UI, depends on your layout and design elements. Word of caution when replacing lots of objects in a huge form: make sure the action can be undone as to not create a ton of rework.

I am wondering if it is really necessary to communicate the technical steps to the user, since the user probably only want's the app to work. What if you do not communicate these steps but rather tell the user what to do. In my answer I assume that each step is only very short. You could show a progress indicator (like a progressbar, filling circle or the like). If step 3 is not working (because the user does not hold the device exactly at the right spot) you could show a message explaning exactly that. Something like "Please hold your phone close to the whatever device". The progress indicator would not go further but should keep pulsating to show that there is still something going on. This way you probably give the user enough feedback and even give the user a clou what to do.

(re)Captcha is just a tool you are using to identify if the user is human and users don't care how you try to do that as long as it isn't bugging them too much. The tool itself doesn't mention it is called reCaptcha to the user (only as a disclaimer), it just says "Select all squares with traffic lights". Most people don't know why it is needed or only understand it partially, but this way it is acceptably accessible. With the error messages it is advisable to follow that principle and keep that acceptably accessible too. It isn't relevant to call it reCaptcha and it isn't relevant to mention if it did fail, expire, explode or whatever went wrong in the backend. All what is relevant is what to do next: try again or contact support. reCaptcha is helping you, not your users. When it fails you are dealing with a robot or you're punishing a user unnecessarily. In that case you want to be informed about the error and give (human) users a link and/or phone number to contact support. Also keep the error message short and functional and leave the appologies to support.

You can cycle the error log by calling sp_cycle_errorlog and then that will close the current error log and cycle the log extensions. Basically, it'll create a new error log file that SQL Server will be hitting. Then the archived error log(s) can be treated accordingly (delete/move with caution). This will not technically "truncate" the log, it'll just roll it over and you can handle the old logs as you so please, like any other file system file. When you do this, you should see a new log file with an entry that resembles the following: The error log has been reinitialized. See the previous log for older entries. BOL reference on sp_cycle_errorlog

SQL Server does not support FOR EACH ROW clause in trigger. So, I think that query in a trigger falls down with an error like this Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, , >= or when the subquery is used as an expression. Maybe replacement of "=" by "IN" will help.

I'm sure there are dba.se and StackOverflow duplicates, but it was far faster for me to post this link: https://feedback.azure.com/forums/908035-sql-server/suggestions/32912431-sql-server-should-not-raise-illogical-errors In short, the Query Optimizer is really free to rewrite the plan as it sees best. Sometimes, it means a column is transformed (CAST -> int) close to retrieval so that it doesn't have to be carried many steps forward before performing the CAST. The only sure-fire way of preventing the error is to look at the CAST expression itself, e.g.: cast(CASE WHEN ISNUMERIC(ENTRY_CODE)=1 THEN ENTRY_CODE END as int)

State codes and their meaning. 1 'Account is locked out' 2 'User id is not valid' 3-4 'Undocumented' 5 'User id is not valid' 6 'Undocumented' 7 'The login being used is disabled' 8 'Incorrect password' 9 'Invalid password' 10 'Related to a SQL login being bound to Windows domain password policy enforcement. See KB925744.' 11-12 'Login valid but server access failed' 16 'Login valid, but not permissioned to use the target database' 18 'Password expired' 27 'Initial database could not be found' 38 'Login valid but database unavailable (or login not permissioned)' More detailed information is available in Aaron Bertrand's blog. To find the status code, you need to inspect the SQL Server Error Log after ensuring that failed logins are recorded in the error log.

From the Connection.setAutoCommit docs: NOTE: If this method is called during a transaction and the auto-commit mode is changed, the transaction is committed. If setAutoCommit is called and the auto-commit mode is not changed, the call is a no-op. But I don't think it's very readable/obvious in your code. You should probably simply commit before switching back to autocommit mode. Makes the intent clear.

I have found the problem: Somehow, MySQL decided to create mysql.sock in /private/tmp rather than in /var/mysql. So, my solution was to create a symlink: cd /var sudo mkdir mysql sudo ln -s /private/tmp/mysql.sock mysql.sock Now everything works fine.

What do you consider to be high-traffic? Turn off Named Pipes and turn on TCPIP It's lighter in it's communication. In my SQL installations, I never use Named Pipes except if the Application is on the same machine as the SQL service, and that's really ... never ... I always separate the application and SQL Server because monitoring and performance measures are more difficult to obtain and decipher. Separate Applications/services from SQL Server Also, if you have SQL and your application on the same server, put them on different servers from each other so that the SQL server is dedicated. Index and stats maintenance Make sure your indexes and stats are all maintained. Sometimes the activity can be high enough when stats and indexes are stale or fragmented that this in and of itself consumes most resources. Especially with standard installs and with no adjustment to CPU and RAM pinnings (see next item). Pinning CPU/RAM to settings so OS/Networks/Services are not entirely consumed by SQL update the CPU Affinity to use all but 1 or 2 cpus (if box has 8 cpus, use 6 or 7 for SQL and leavning 1 or 2 unchecked for the OS/Network/Services to use) set the MIN and MAX RAM for the SQL Server to be "pinned" at the same RAM setting (if box has 8GB or RAM, set MIN to 6144KB and MAX to 6144KB), or something where MIN=(MAX Machine RAM * 20%) or MAX=(MAX Machine RAM * 10%) rounded to multiples of 1024KB. These last two settings help to make sure that the resources for the SQL are not entirely consumed by SQL and the OS and Network and other services can respond and perform their standard requests. I've had situations where so much activity was happening (1K of simultaneous users, all indexes, stats, etc were good) that the box resources were completely consumed by SQL and the network services reported that the box could not be reached. Once I made these changes, and have been doing this ever since, many of my resource-consuming problems have gone away. You could even try these last two with Named Pipes on and it should work because the Network can respond with the high traffic. But I would recommend TCPIP instead.

Based on a_horse_with_no_name's comment, I started searching around psql and found the solution: \set VERBOSITY verbose SELECT * FROM tgvbn(); ERROR: 42883: function vfjkb() does not exist ... Now that goes into .psqlrc. Details and further options can be found in the psql documentation.

There's really no database involved. You can see it hits no tables. But yes we've run this "in" several databases and run CHECKDB against them just to be sure. The database involved is tempdb (database ID 2). That's where the value of LOB variables gets written. You can see that by looking in the sys.dm_db_task_space_usage DMV (if your query weren't failing with an error, that is): My data database context for that query was "master," but notice that the database_id in the query results in tempdb. So you could check tempdb for corruption. This database gets recreated each time the server is restarted, so I'd be surprised if you have persistent corruption there. Unless you're having disk issues, in which case you should consistently see errors in the Windows "System" Event log that indicate corruption. All that said, it's also very possible this is a bug in SQL Server 2008 R2 SP3. There is at least one non-security-related hotfix to that SP (KB3033860). The errors mentioned there don't look like they match your situation, but could be related (they are assertion failures). Unfortunately, since SQL Server 2008 R2 is out of support, this won't be fixed even if it is a bug. Your best bet is to try and work around the problem, or upgrade.

There might be a way to rearrange parts of the correlated subquery so that it can reference the outer level's products_id directly, rather than in a subquery/derived table of its own, but in the end I had too little patience to find it. Instead, I can offer you a different approach to calculating the same results, which uses variables: SELECT p.products_id , ( SELECT SUM( DATEDIFF(to_date, GREATEST(from_date, CURDATE() - INTERVAL 400 DAY)) * factor ) FROM ( SELECT IF(h.products_id = @p, @d, CURDATE() + INTERVAL 1 DAY) AS to_date , @d := h.inventory_date AS from_date , (quantity > 0) AS factor , @p := h.products_id AS products_id FROM inventory_history AS h ORDER BY h.products_id ASC , h.inventory_date DESC ) AS v1 WHERE v1.products_id = p.products_id AND v1.to_date >= CURDATE() - INTERVAL 400 DAY ) AS count FROM (SELECT @p := null, @d := null) AS init , products AS p WHERE p.master_categories_id=264 ; With the help of two variables – @p to keep track of the current products_id, and @d to carry over inventory_date to the preceding record of the same product – the v1 derived table turns inventory_history into a set of date ranges, with a flag (factor) to indicate whether the range qualifies for the count result or not. The derived table's definition is two levels deep, so it cannot reference the main query's products_id. It simply returns the entire set. However, the SELECT that is using v1 is where p.products_id is valid, and that is where filtering on products_id happens. The count itself is then simply a matter of adding up the date ranges' lengths, using the DATEDIFF(end_date, start_date) function. The starting day expression (GREATEST(...)) simply makes sure that the earliest date range's starting point, for the purposes of the query, is no earlier than 400 days from now. Here is a link to a live demo of this solution at dbfiddle.uk using your test setup: https://dbfiddle.uk/?rdbms=mariadb_10.3&fiddle=dc5baefec8902a99bf807115aaa235ba