Is it just a plain print to screen? if it is why not simply use simple console print command?
I've looked it up and there isn't much information about it. Even in the official PostgreSQL guide there isn't information about it other than the fact it exists.
Is it preferred to use plpy module because that way the information to be printed won't be logged in PostgreSQL log file?
The PL/Python plpy.notice(msg) method and its cousins, plpy.debug(msg), plpy.log(msg), plpy.info(msg), plpy.warning(msg), plpy.error(msg), and plpy.fatal(msg) are used to generate messages using PostgreSQL's logging capabilities. The error and fatal variants also raise an exception which can be used to abort the current SQL transaction. plpy.notice(msg) is equivalent to the PL/PgSQL command RAISE NOTICE msg.
According to the PostgreSQL 9.4 documentation http://www.postgresql.org/docs/9.4/static/plpython-util.html, the destination of log messages at various levels can be controlled via database configuration variables. For example, you can specify that you only want messages of at least WARNING level to be dispatched to the client, but anything from NOTICE and above to be logged to the server log. This has been the case at least back to PostgreSQL 8.0.
Related
Is it possible to replay all failed messages through nServiceBus without using ServiceControl/ServicePulse?
I'm using NServiceBus.Host.exe to host our endpoints. Our ServiceControl/ServicePulse database became corrupt. I was able to recreate it, but now I a few failed messages in our SQL database which are not visible through the ServicePulse.
Will this help?
Take a look at the readme.md
For people who want the functionality that this tool previously
provided please take one of the following actions
Return to source queue via either ServiceInsight or ServicePulse.
Return to source queue using custom scripting or code. This has the
added benefit enabling possible performance and usability
optimizations since, as the business owner, you have more context as
to how your error queue should be managed. For example using this
approach it is trivial for you to choose to batch multiple sends
inside the same Transaction. Manually return to source queue via any
of the MSMQ management tools. If you still want to use
MsmqReturnToSourceQueue.exe feel free to use the code inside this
repository to compile a copy.
You can look at the link provided to build your own script (to mach SQL) and trip the error message wrapper so you can push the stripped message back to the SQL queue.
Does this help?
If not please contact support at particular dot net and we will be glad to help :-)
There is nothing built into the Particular stack that I know of that will take care of this.
When I have ran into issues like this before I will usually setup a console application to send some commands into the endpoint and then setup a custom handler in the endpoint to fix the data inconsistencies. This allows you to test the "fix" in a dev/uat environment and then you have an automated solution for production to fix the problem.
I guess by default only error with severity 20-25 will gets logged into SQL Server error log file. How can I change the config to log even other errors which are less severity? Or where I can find less severe errors getting logged in SQL Server? I am interested in errors such as
could not find stored procedure spName
etc.
I extracted the following block from this article, which would be a good starting point to explore the SQL Server error log config changes.
Logging Errors
SQL Server Agent takes these errors from the error log, so if follows that the errors must be logged in the first place. There is no way of attaching alerts to errors that aren't logged. All error messages with a severity level from 19 through 25 are written to the error log automatically.
So, what if you want to log information messages, or messages of low severity? If you wish to have an alert on any errors that are of a severity less that 19, then you have to modify their entry in the sysmessages table to set them to be always logged.
You do this using sp_alterMessage with the WITH_LOG option to set the dLevel column to 128 . If a message has been altered to be WITH_LOG, it is always subsequently written to the application log, however the error happens.
Even if RAISERROR is executed without the WITH LOG option, the error that you have altered is written to the application log, and is therefore spotted by the alert. There are good reasons for wanting to do this, as it will then log, and optionally alert you to, syntax errors that are normally seen only by the end-user.
You can force any error that is triggered programmatically to be written to the error log by using the WITH LOG parameter with the RAISERROR command. So, with a user-defined error severity (9) you can log an incident, cause an alert to be fired, which in turn emails someone, or runs a job, simply by using RAISERROR.
Naturally, because the job that responds to the alert can be run by the Agent under a different User, you do not need to assign unsafe permissions to the ordinary user. You can use xp_LogEvent if, as is likely, you do not want the user to see the error. (Only the Raiserror call can utilize the 'PrintF' formatting placeholders in the error messages, so logging the error with a formatted message using xp_logevent results in a literal recording of the message, string format identifiers and all.)
I would recommend to refer the original article for more/detailed information on this.
Please follow this link to find out more on severities.
I am developing a JDBC driver which is a wrapper for a web service. My unit tests work fine and I can write my own Java code that uses the driver to do useful things.
When I plug it into Squirrel SQL it is able to connect and get its initial batch of metadata (properties, schemas/catalogs, etc), but a simple SELECT query does not work. I receive an InvocationTargetException. This means a reflective call failed inside the method or constructor being invoked: this exception always wraps another exception which shows what really failed.
However, the error window in Squirrel SQL simply shows the exception name: no wrapped exception/cause, no stack trace. The log in my user directory contains no information regarding what happened.
Looking through the global properties and connection properties, I have not found any settings that would increase logging. I am using Squirrel SQL version 3.5.3 on Java 7 64-bit, Windows 7 64-bit.
How can I get Squirrel SQL to provide more information to help me find the cause of this error? I do not care if it outputs to the log file or the error window, just so I have something to go by.
The easiest way to change the log level is to edit the log4j.properties file. This file is in the same folder as the batch file that starts SquirrelSQL.
Simply change the line
log4j.rootLogger=info, SquirrelAppender
to
log4j.rootLogger = debug, SquirrelAppender
I have a couple of threads and I'm using SQLite for storage. When I'm trying to access the database I'm getting SQLITE_BUSY error.
Is there a way how to fix this problem other than trying at each request ?
You are most likely running in serialized mode. But ... you're probably looking to run in multi-threaded mode instead. Note that you will need a separate database connection in each thread if you go that route.
Here is the link to the documentation goodness: http://www.sqlite.org/threadsafe.html
Ignore my last answer.
You can use the sqlite3_errmsg function to get the error message as string and print it using NSLog or other ways as soon as error occurs to find the more appropriate and proper reason.
http://www.sqlite.org/c3ref/errcode.html
You probably seem to be running in to serialization issue; I am not sure where.
I got the following SQLException: "invalid options in all7"
Upon googling the error message, the ONLY hits I saw were Oracle error lists which pinpointed the error at "ORA-17432: invalid options in all7". Sadly, googling for the error # brought up only combined lists with no explanation for the error, aside from this page that said "A TTC Error Message" as the entire explanation.
The error happens when a Java program retrieves data from a prepared statement call executing a procedure that returns a fairly large, but not unreasonable, # of rows via a cursor.
I can add the stack trace from the exception as well as condensed code, but I assume that's not terribly relevant to figuring out what "ORA-17432: invalid options in all7" means.
Context:
Error seemed to have appeared when the Java program was migrated from Oracle 9 OCI to Oracle 10.2 thin client. The procedure, when run directly against database (via Toad) works perfectly fine and returns the correct cursor with correct data and no errors.
This seems to be something data specific (result set size may be?) since running that same exact code against a different currency as a procedure parameter (which returns much smaller resultset) works 100% fine.
This is almost certainly not something you're going to have control of. It looks like a problem with the way your thin driver is using the two-task common (TTC) protocol. One thing to note is that this sort of thing can be very sensitive to the version of the driver you are using. Make absolutely certain that you have the latest version of the JDBC driver for the combination of the version of Java you're using and the version of Oracle on the server.
Akohchi - you were in the right area though not quite correct. The explanation obtained via Oracle Support call was that this version of Java (1.3) was not compatible with new Oracle. Java 1.4 fixed the issue.