Db2 database creation problem - sql

I've just installed DB2 v8.1.18.980. Now I try to create new database. I'm getting the error with the following sql codes:
sqlcode : -902
sqlstate : 58005
Unfortunately the error itself in Russian, as a result, I cannot paste it here. Official site says the following about the problem:
"The statement cannot be processed. The application program is not permitted to issue additional SQL statements. For example, a recovery routine associated with the application program may not issue additional SQL statements.
Programmer response
Rebind the failing application program and try again. If the problem persists, examine your DBRM and make sure it matches your program."
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z9.doc.codes/src/tpc/n902.htm
But, it's not clear to me. Any ideas, what can be wrong and how to resole it?
I'm using Windows 7 Ultimate if it may be an issue.

The documentation you linked to is for db2 v9 for z/os, not db2 v8 for Windows. So that's the first problem.
The documentation for v8 has this to say about SQL 902:
A system error (reason code = reason-code) occurred. Subsequent SQL statements cannot be processed.
Explanation:
A system error occurred.
User Response:
Record the message number (SQLCODE) and reason code in the message.
If trace was active, invoke the Independent Trace Facility at the operating system command prompt. Then contact your technical service representative with the following information:
Problem description
SQLCODE and embedded reason code
SQLCA contents if possible
Trace file if possible.
Federated system users: isolate the problem to the data source failing the request (refer to the Troubleshooting Guide to determine which data source is failing to process the SQL statement) and take the necessary diagnostic steps for that data source. The problem determination procedures for data sources vary, so refer to the applicable data source manuals.
sqlcode: -902
sqlstate: 58005
Which brings us to the second problem: it's asking you to contact IBM and open a ticket, and as far as I know v8 is out of support so it won't be that easy.
I think installing v9, v9.5 or v9.7 would be your best bet, unless you have a really compelling reason to stick with 8.

Related

Data Migration Assistant

I am using Data Migration Assistant to assess compatibility issues migrating a SQL database to Azure SQL. After running for a couple of minutes, it throws an error saying "The file contains the XML node type {0}. This type is unsupported or in an unsupported location." I have successfully assessed other databases using DMA but this particular database always aborts after throwing this error.
I decided to go ahead and migrate the database using the wizard (Deploy Database to Microsoft Azure SQL Database) from SSMS, and ran into several compatibility issues that showed as errors. The database had several triggers that were created by a third-party database tool that referred to table objects with the 3 & 4-part naming conventions which is not supported on Azure SQL. There were several other errors in addition to these but I decided to delete these triggers first and run Data Migration Assistant again. This time it ran to completion and I got compatibility report. I am not sure if it was the sheer number of issues found or something in those triggers that I deleted had caused the error.

SQL - Attempted to read or write protected memory

I'm trying to use a functions on the SQL SSMS2014 and I get the error on the title.
I can create new tables and databases no problem if i do it with a new query, but afterwards i can't edit or use the design function without getting that error on any of the databases that i have.
Most of the similar errors i found were related to connection to the database, but none of the fixes on those worked for me.
My guess is that the error message you are getting is:
the backend version is not supported to design database diagrams or tables
Solution:
This is commonly reported as an error due to using the wrong version of SMSS. Use the version designed for your database version. You can use the command select ##version to check which version of sql server you are actually using. This version is reported in a way that is easier to interpret than than shown in the Help About in SMSS.
Using a newer version of SMSS than your database is generally error free, i.e. backward compatible.

I am getting a DB collation error when loading data

Hi I am loading the data from MySQL staging to MySQL destination.
I get this error and it says Illegal mix of collations (latin1_swedish_ci, COERCIBLE) and (latin1_german1_ci, COERCIBLE) for operation '='
Does this has to do anything with Pentaho. Because the same runs fine in Production server but gives error in Dev server.
Probably not Pentaho since it is working in one area, but not another. Try:
Moving the code from your prod box to your dev box to make sure you didn't introduce any changes unintentionally.
Are your MySQL instances the same versions? Are they supported by Pentaho? What about your drivers? And are the drivers all stored in the correct places? Make sure that you don't have two of the MySQL drivers in the different folders to avoid conflicts.
Run the job in row level mode to see the most messages about what is occurring. It could give you important clues.

Is this sql statement vulnerable?

I just took over management for a webservice and today i got a user report about this error. Now i'm no sql injection expert but does this error make this attack possible?
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[MySQL][ODBC 3.51 Driver][mysqld-4.1.22-community-nt]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 '') ORDER BY TCOL_date desc' at line 1
I'm asking because for some reason i'm not given access to the code and the previous guy insists that the site is safe so i need to come with some proof or facts that it's actually vulnerable.
Thanks in advance for any help.
In short Not really... but.
While this might provide more information than you're comfortable with (version of MySQL running, drivers being used, and a little about a couple of columns), it's not going to open you up to an attack as much as showing the whole SQL line would. Someone could try to blind hack it to get more information, and the fact that it's showing any info at all is a lot worse for you from the standpoint of an attacker trying to get in than showing info only in the logs. Feedback, even a little can aid an attack[er].
If by trying to insert various bits of code into the form you can get a response that prints your own content you're inserting this would be much more beneficial to an attacker. The fact that this application breaks when you insert a ' leads me to believe that it's not as secure as the programmer claims. This might also lead an attacker to look for another avenue of attack. If they can insert javascript code into a form and have it display in a profile, or if they can inject code that's executed upon return from the server, then they could exploit the server and use it to launch their own attacks.
The problems with SQL injection come back to [code] implementation and the types of things allowed (and blindly processed) by the forms. For instance if you could escape a single quote \' in your current situation, someone could open and close the SQL statement and possibly UNION their own statement when pulling a query. If they could close the statement and append another statement, they might add delete from users where 1=1 or something of that nature. Another way might be if you can type in <marquee>Test</marquee> and it prints the word "test" scrolling when it finds no results then you can perform injections because it's not stripping out code.
This all leads back to permissions. The permissions on the server should make it so the users on the front end of the site only have access to the permission levels they need. If they're only querying the database (SELECT), they should not have access to INSERT, UPDATE, DROP TABLES, or DELETE.

More informative error messages from a SQL server

I am using SQLite.
When I execute a query, I get error messages such as "error near select" or "error near ','". I wish it would give me a line number or statement number.
After loading a trigger and encountering an error either in syntax or at run-time, I must go back to my editor and make changes. Then I have to execute a drop trigger command before reloading the trigger.
Is there a good SQLite browser or command line tool that provides more information than the one I am using?
Setting aside the implementation differences, would it make more sense for me to switch to mySQL?
Using a different browser for SQLite wouldn't make that much of a difference since it would use the same library. Switching to MySQL in my experience is not a trade up in terms of error messaging, it's about the same or worse in my opinion. PostgreSQL, however (again in my experience), has much better error messaging, although it can at times be just as cryptic as MySQL or SQLite.