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.
Related
Apologies first of all if there is an answer to this elsewhere on the site. I've checked some of the proposed solutions and can't find anything appropriate.
So I've got this SSRS report that works fine when deployed but won't run locally during testing. The main query itself works when run in the query editor, as do all the sub queries that provide data for parameter drop lists but when I try to preview it, I get the error.
Bear in mind it used to work, up until the end of last year, which was when it was last updated.
I've tried removing all the tables and matrices on a copy (replacing with one very simple table), the parameters went too and I still get the error. I've also downloaded the server version, renamed it and redeployed it, works online, but not locally. As the error message is brutally vague, I've run out of ideas of things to try. Apart from switching over to PowerBI, can anyone think of anything else I could do to understand where the error is from?
Possibly relevant - the main query has some recursion in a subquery, but only a couple of levels. Could this be related? As I've said before, it used to work...
PS I'm using VS 16.7.2 from server V13.0.4466.4
PPS I also added the query to a brand new report and it errored so I think it must be something related to the SQL itself?
I've created and compiled a program in Cobol, but when trying to run and test it with a JCL job, I'm getting this error when reading the output. (The program compiles and the job runs without errors themselves)
SQLCODE = -991, ERROR: CALL ATTACH WAS UNABLE TO ESTABLISH AN IMPLICIT CONNECT OR OPEN TO DB2. RC1=0008 RC2=00F30034
SQLSTATE = 57015
Now I don't understand why this error occurs. The DB2 database is up and running, I can access it myself. I can't find an error in my program code either. Googling it sadly doesn't provide me a clear solution, all I can find is that the issue is either the compiling job for the program, the jcl to run it or issues with the DB2 itself.
Have you done a bind and did it work !!!, The error indicates the plan does not exist or is not authorized.
You need to talk to people at your site about the Compile/Bind process and who
authorises
If you do not know know about Mainframe Cobol/DB2 compile process, try
reading this
Basically --->
Cobol program
Cobol DB2 Program ---+----> with no SQL ---> Compile -----> Executable
| but calls Plan
|
+----> DBRM (SQL) -----> Bind ------> DB2 Plan
It is the plan that needs the DB2 authorisation to run the SQL !!!
You might be able to authorise the Plan or you might need to see the DBA's
With DB2 COBOL, There is Co-Compiler (was a pre-compiler) that strips out
the SQL and creates the DBRM (basically a a special SQL procedure).
It is the Bind that processes the DBRM (SQL) and creates DB2 access plans
This may seem long winded after java etc. But there are some advantages
The SQL is processed ahead of time and not while the program is running
You can check the DB2 access path at any time - Before / after execution. Useful for
analysing performance issues.
The same DB2 access paths are used from one run to the next. This leads to
fairly predictable run times.
I want to make sure the new procedure valid, insteading of the DB2 always query by the cache pool, I have to rebind the database (db2rbind command). And then I deploy the application on WebSphere. BUT, when I login to the application, the error occurs:
The cursor "SQL_CURSN200C4" is not in a prepared state..SQLCODE=-514 SQLSTATE=26501,DRIVER=3.65.97
further more, the most weird thing is that the error just occurred only once. It will not never occur after this time, and the application runs very well. I'm so curious about how it occurs and the reason why it only occurs only once.
ps: my DB2 version is 10.1 Enterprise Server Edition.
and the sql which the error stack point to is very simple just like:
select * from table where 1=1 and field_name="123" with ur
Unless you configure otherwise (statementCacheSize=0) or manually use setPoolable(false) in your application, WebSphere Application Server data sources cache and reuse PreparedStatements. A rebind can cause statements in the cache to become invalid. Fortunately, WebSphere Application Server has built-in knowledge of the -514 error code and will purge the bad statement from the cache in response to an occurrence of this error, so that the invalidated prepared statement does not continue to be reused and cause additional errors to the application. You might be running into this situation, which could explain how the error occurs just once after the rebind.
I have written a program in vb.net for in house use that connects to a Progress OpenEdge database. Now I'm having a really weird runtime problem.
I have a .exe file that runs on my local C: drive, the C: drive of the servers, from a certain network Location (but not other places on the network) just fine on at least two regular users. The problem is that when I submit it to my IT manager for review she gives it back and says it wont even run; on looking at the error, it seems to fail on the very first select query (which happens before the form finishes loading) Specifically, it ultimately boils down to the error below:
System.Data.Odbc.OdbcException: ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Number contains an invalid character: ?
ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Number contains an invalid character: ?
now, certainly, I'm using data sources in visual studio and parameterized queries. So, yes, if it's trying to run it as straight SQL and not filling the parameters like it's supposed to, then there is a question mark in a number field. My question is: why does the same .exe, in the same place, run by a user with HIGHER privileges throw errors?
Are you initializing the integer variable with zero (0). The question mark in progress means unknown value.
If you are still running into a problem or haven't verified a solution yet, maybe check this KnowledgeBase article on SQL tracking out to make sure that the interpretation/execution of these statements is correct.
Providing that everything is the same with the SQL statements, the problem is most likely with the way the .exe is being run. There may be filling with an alpha character rather than numeric input depending on how the .exe is being run.
UPDATE
As Mathias notes below, this exact problem has been reported and resolved here:
ASP.NET-MVC (IIS6) Error on high traffic: Specified cast is not valid
ORIGINAL POST
This may be too specific a debugging issue to be posted here, but I'm posting it anyway in the hopes that it produces a solution that others find useful.
I have a web application that operates under moderate load -- maybe 5 requests per second. It has some older code talking to Sql via ADO.NET + DataReaders and has been using this same technique for at least five years without problem. It also has some newer code using LINQ-to-SQL. Both techniques use the same connection string to maximize connection pool reuse.
Recently I'm experiencing a very weird behavior described by these symptoms:
Everything will work perfectly for about a day, then suddenly every call (or nearly every call) to the data layer (both ADO.NET and LINQ) returns data that cannot be parsed by my code -- I'll get exceptions like "Unable to cast object of type 'System.Int32' to type 'System.String'." or "Sequence contains no elements" or "IndexOutOfRangeException" or "Invalid attempt to call Read when reader is closed".
Interestingly, I never get exceptions from SqlCommand.ExecuteReader() or DataReader.Read() -- the exceptions only occur when I try to parse the IDataRecord that is returned.
I am able to fix the problem temporarily by restarting either Sql or IIS. After a few hours it comes back again.
I've tried monitoring the number of connections in the connection pool and it never goes above 3 or so. Certainly never above 100.
I'm not getting anything in the event log that indicates any problem with Sql or IIS.
The drive has 9 GB empty space.
I suspected bad RAM, but the server is using registered ECC DIMMs.
I have other applications using ADO.NET that work fine and never exhibit the problem.
When the problem is occurring I can call the exact same stored procedures via Management Studio and they return the correct, expected results.
Here is my pattern for ADO.NET access:
using (var dbConn = Database.Connection) // gets already-open connection
{
var cmd = new SqlCommand("GetData", dbConn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.AddWithValue("#id", id);
SomeDataObject dataObject = null;
var dr = cmd.ExecuteReader(CommandBehavior.CloseConnection | CommandBehavior.SingleRow);
if (dr.Read())
dataObject = new SomeDataObject(dr);
dr.Close();
return dataObject;
}
Theory: Is it possible that the combination of ADO.NET in one part of the code and LINQ in another part of the code, both using the same connections from the connection pool, is having some weird side-effect?
Question: Are there any debugging steps I should be trying? Any events logs or performance metrics that might help?
20+ open connections on 5 hits/second is a red flag to me. We have close to 100 hits/sec and hover around 10 connections.
What about memory use? Is it high?
I suspect you're having problems with releasing resources. I'm still getting my feet wet with LINQ to SQL and I too have a long positive expereince with ADO.NET. I wonder if you're missing a pattern with LINQ to SQL that cleans up connections, etc.
Try this - can you isolate the ADO.NET code from LINQ in the application? If you ONLY make ADO.NET calls, what happens to memory, connection count, etc? Then add in the LINQ stuff and see how it affects it.
Resource problems seem to 'start up late' becuase they take a while to accumulate.
UPDATE
I found someone on SO who apparently has the same issue
ASP.NET-MVC (IIS6) Error on high traffic: Specified cast is not valid.
It is expained in the answer from ATLE
ORIGINAL POST
I have seen issues in a linq-to-sql application when under load. I used MVC - Storefront from
Rob Connery so I guess a lot of people use this kind of application layout.
The application worked perfectly when under little load, but there where strange errors that sounded like the one you describe when under medium load.
I suspected that it was an issue with where the db-context was stored.
In my case it was easy to reproduce: I used jmeter and had 5 threads each having a couple of requests per second (20 I guess). I realy needed to have load originating from multiple threads.
So my advice is: Try to reproduce the error in development by creating some load with Jmeter (not good for ASP.NET but for ASP.NET MVC) or application center test.