I am working on a VB.Net application. The application sometimes throws sql exceptions. Is there a way to pull the sql statement that threw the error? If not, what is a work around?
Related
I'm developing an app in vb6 and I'm trying to do queries on SQL AZURE thanks to the SQL Server Native Client 11.0 but each time I execute a query (even a simple select * from Users;) the Native Client returned this error :
[Microsoft][SQL Server Native Client 11.0][SQL Server] Executing SQL directly; no cursor.
This problem occurs since I have created a new DB with a different level on azure portal. The database before was a web DB and the new one is a Standard DB. Is there a manip to do for the three new versions of DB in Azure(Basic,Standard,Premium) ?
Thank you very much for your help
The error in question is 16954 (your error reporting should first and foremost show the error number, state and severity, not only the error message). It occurs when an application attempts to use server side cursors in a context not supported. See Client-Side Cursors Versus Server-Side Cursors. This is likely coming from your cursor library choice in RDO, see Choosing an RDO Cursor Library. Switch to rdUseIfNeeded or rdUseNone.
I believe the underlying error is getting hidden by the sql client.
If you are getting an error for simple select * from table queries then I would check you have permissions for the credentials your app is using.
I am trying to execute on Impala a parameterized query from Pentaho (version 5.0.6) CDE using the ${parameter_name} notation. I found out that if I remove the parameter and I hard-code the value in the SQL query, everything works fine, but if I put the parameter, everything stops working with the generic error message "Error processing component" (I am using the table component of CDE to show the values). In the pentahobaserver-stdout log file I found the following exception:
Jun 24, 2014 3:01:08 PM com.sun.jersey.spi.container.ContainerResponse mapMappableContainerException
SEVERE: The exception contained within MappableContainerException could not be mapped to a response, re-throwing to the HTTP container
java.lang.NoSuchMethodError: org.pentaho.reporting.engine.classic.core.ReportDataFactoryException.getParentThrowable()Ljava/lang/Throwable;
Which seems to be a too generic error message (caused by this bug http://jira.pentaho.com/browse/CDA-79)
After some more investigation on the web, I think I bumped into this problem. For now I cannot avoid neither the use of parameters, nor the use of Pentaho nor the use of Impala, thus, I am stuck. Is there a workaround to this problem?
Thank you in advance :)
Not really. The JDBC driver for Impala does not support parameters in PreparedStatements which is what is used in the Reporting libraries.
It's a hard one to solve. Probably the best way to workaround it is to use a Kettle transformation that dynamically builds the queries and issues them to Impala.
That way, parameter handling will be done at the Kettle level, but for Impala it will be a static query.
How can I capture queries that fail on the SQL Server due to connection drops/failures?
Profiler doesnt seem to capture if there is a connectivity loss.
Without catching the exception in the code this is not the easiest thing to do.
Have you checked the error logs in SQL? DA has a related answer for doing this: https://dba.stackexchange.com/questions/10364/sql-server-error-log-monitoring
You can check that your profiler is set up correctly:
http://support.microsoft.com/kb/224587
There are a number of sql monitoring tools out there, just google 'SQL server monitoring'.
I have a database that I am trying to connect to through SQL Plus. I run this command from the command line:
sqlplus username/password#//hostname:port/sid
I use this connection string instead of using tsnames. The error I keep getting is
ERROR:
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor
The weird thing is that using the same connection information I can connect just fine through SQL Developer. I can see the tables, users, and everything else. Anyone know what could be going on?
P.S. I tried setting up tsnames but it just gave the same thing as using the connection string.
So my boss found the solution. Turns out the sid is different when connecting through SQL Plus then through SQL Developer. Seemingly in just this one case. I have no idea why this is but that was the reason. Very odd and I don't understand why.
We are using SQL 2005 and the try-catch functionality to handle all of our error handling within the DB. We are currently working on deploying a .NET CLR function to make some WCF calls in the DB. This WCF procedure is written in the CLR and then deployed to SQL. If I put a try-catch block in the CLR code, it catches the error fine. However, I can't seem to throw the error up to the try-catch block in SQL. SQL seems to ignore what I throw it and catches the error it finds. Is there no relation between the two (i.e. I can't throw from one to another?)
If I can throw from within the CLR to the calling procedure in SQL, is any special formatting needed? I tried a specific case of catching the error that was thrown, and then throwing a different error, but SQL ignored my thrown error and caught the original error, as if it ignored the thrown error.
Here is a blog post that covers it at a highish level:
Exception handling in SQLCLR
When SQL server execute a user function/procedure/trigger implemented in CLR (i.e., managed code), we will install a managed exception handler around the user code. So if the user code leaked a exception, the server will catch it and throw a TSQL exception wrapping the user exception.
This seems to imply that it will just work.