Today I had to rebuild our BugZilla installation. It has been painful, mainly because I unintentionally incurred an upgrade from MySQL 5.7 to MySQL 8.0. Now BugZilla is reporting an SQL syntax error. In an attempt to debug this, I connected directly to the database using the MySQl client and ran the following query:
SELECT * FROM groups;
This results in the error:
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'groups' at line 1
The same query works for any other table, just not "groups". I am exhausted and have no energy left to solve this. I am guessing that MySQL 8.0 introduced "GROUPS" as a keyword. I would appreciate some help.
Upon investigation it turns out that MySQL 8.0 has indeed introduced "groups" as a keyword, and BugZilla needs to be modified to quote the table name in all places. Unfortunately the database code is shared among many different types of database which all use different characters to quote table names.
My final solution was to switch to using PostgreSQL.
Related
After upgrading from Oracle 11/12 to 18/19 I get this error: ORA-01036: illegal variable name/number.
The error occurred in a query like this:
SELECT * FROM (SELECT * FROM TABLE) MY_TABLE WHERE ROWNUM <= :P_ROWNUM
(Subquery + binding parameters)
The identical query works properly with the Oracle 11.2.0.4 or 12.1.0.2 client. It fails with the Oracle Client 18c or 19c.
PS: The Oracle Server is version 18c 64x for Windows.
I use Delphi 10.1.2 with ADO components (dbGO). I also tried with Delphi 13.3.3 but the behavior is the same.
It seems to be a problem in the Oracle OLE DB provider (ORAOLEDB).
If I don't use ADO but DevArt Unidac all worked as expected.
Someone can help me?
Max
Your query is fine. We ran into a similar issue when migrating from 12.1 to 19. In our case, we have a custom OLE DB provider that interfaces with OraOLEDB (and others) using the Microsoft OLE DB Provider Templates (ATL). When attempting to upgrade from 12.1.x to 19c we started seeing the strange and confusing "ORA-01036: illegal variable name/number" error for parameterized SELECT queries. The queries would succeed the first time they were executed but subsequent executions would fail when all we did was change the parameter value (the queries were executed sequentially). I went on a wild goose chase trying to diagnose the issue and finally decided it had to be an Oracle caching bug of some kind. Yesterday, I experimented with the cache-related connection string attributes and found that adding the MetaDataCacheSize attribute and setting its value to 0 (zero) resolved the issue for us. None of the current Oracle patches appear to address this issue, at least none of those that mention the ORA-01036 error.
I am using Oracle SQL Developer version 4.1.0.19.
So this can be a very simple issue but I cannot seem to find the solution anywhere as I have just started using SQL Developer.
I type in this query
create table Student(Stu_id INTEGER,Stu_name VARCHAR(60),Stu_email VARCHAR(60))
select * from Student
And when I Run the SELECT query, I get an error something like this:
Method oracle/jdbc/driver/T4CCallableStatement.isClosed()Z is abstract
I have no idea as to why this is happening , this may be very stupid but I cannot seem to find a solution.
BTW I am using Oracle 11g version.
How did you install SQL Developer? Can you download the zip off of OTN and extract it to a fresh directory and try running it from there?
Your error message indicates something VERY bad is wrong with one of the drivers. Which makes me wonder if you messed with one of the JARs or are attempting to use an old Oracle Client with a THICK connection.
After searching here and on the web, I finally decided to post the question. I am running an SQL 2000 server, and linked an Oracle 9i server. Everything works fine when I run queries, and even updates and inserts from and to the Oracle Linked server (using both Microsoft OLE DB driver and Oracle OLE DB driver) using the OPENQUERY approach.
The problem is that, in order to clean code a bit, I want to use four part names in my queries. I am doing this also when querying other SQL linked servers.
But when I run the queries against Oracle using four part names I get this error: ( I am translating the error message from spanish. Probably the original message in english id different)
ERROR: OLE DB 'MSDAORA' returned an invalid column definition.
Error Code: 7318
Digging a bit, I learned that this is probably related to nos having the right collation name set in the linked server properties.
Now... I am not an Oracle expert, so I need to find out what collation is the schema I connect to using in Oracle (apps... yes, I know, I know... )
So, the plain question is... How do I find out what collation Oracle is using? I have access to the Oracle server via Toad... is there any query I can run in order to find this out?
Thanks!
I think you're looking for the NLS settings, which you can find from these views:
V$NLS_PARAMETERS — "Current values"
NLS_DATABASE_PARAMETERS — What the database was created with.
NLS_INSTANCE_PARAMETERS — From changes by ALTER SYSTEM
NLS_SESSION_PARAMETERS — Combined, plus ALTER SESSION
V$PARAMETER — System parameters, where a lot of this is changed (contains all kinds of stuff)
The documentation is rather lacking here (or, quite likely, I couldn't find the right document), but this should get you what you want.
You will probably have to log in as SYSDBA to read some of these views.
I am trying to migrate my Oracle db to SqlServer 2008 using SSMA. I defined some type mappings for columns. When I synchronize after converting schema it gives errors like: "Cannot find datatype datetime" or bit. These datatypes are valid SQL Server datatypes.
Why I am getting these errors?
Just a guess, but it's quite hard to provide more than that before you give more details... (the code being synchronized to SQL Server, first of all).
Do you have case-sensitive collation on your SQL Server? I believe SSMA may have problems in this case. Try synchronizing to case-insensitive DB.
Also you may try running generated SQL Server (translated) code in the Management Studio and then find the problem with generated SQL or DB setup from that point. Again, it's most likely possible to figure out the problem solely by looking at your generated SQL if it's indeed corrupted due to some bug in SSMA.
I have a web app hosted on BEA Weblogic 10.x with an Oracle 10g database backend.
It works perfectly with one database, but when we make a clone of it and try to use a different WebLogic and Oracle instance we are getting this error:
ERROR - Problem initializing invocation tracking - disabling
tracking xxxxclass.BadTableMappingException: Database column
xxxxPeriodEnding in database yyyyyyy, table zzzzzzz has an
unknown type: JDBC Type 91.
We get it every time we do a query that involves a column of type DATE. There was no ORA-XXXX code in the message.
I can access the database using SQL*Plus using the same access and do selects and updates on the same tables with no errors.
The answer to this question is not just a simple description of what a type 91 error is (although that will help) but what could be causing this given the circumstances described above.
I am using ojdbc14.jar for JDBC on both instances of weblogic.
I have no idea about the error, but have you considered the jdbc jar version and more importantly if the oracle DB needs to be updated.
I faced very weird problems with oracle, and struggled for a while to find at the end that installing some patches for oracle would solve the problem.
Set oracle.jdbc.V8Compatible=true.
This remaps the oracle DATE type to a DATETIME time in JDBC. This parameter was missing on the new Weblogic server.