Snowulf » Database

Error: SQL1159 Initialization error with DB2 .NET Data Provider, reason code 10, tokens 0.0.0, 9.7.0

John — Tue, 20 Jul 2010 17:00:22 +0000

This past weekend I spent way too much time with Jon while trying to get our new work machines setup. Normally most of the time is spent waiting for Visual Studio to install (seriously that thing takes forever), but not so this time. DB2 kept refusing to work and play well with others. Specifically the driver that .NET uses to communicate with, and thus began several hours of googling and downloading and installing.

Before installing anything more than just Visual Studio 2005 (and doing a build of course), I tried to login and got:
Could not load file or assembly 'IBM.Data.DB2, Version=9.0.0.2, Culture=neutral, PublicKeyToken=7c307b91aa13d208' or one of its dependencies. The system cannot find the file specified.
This wasn’t surprising as I had not yet installed any DB2 drivers.
So then I went and installed what I thought was the correct bit (ibm_data_server_client_win32_V97.zip) and got:
SQL1159 Initialization error with DB2 .NET Data Provider, reason code 10, tokens 0.0.0, 9.7.0
After scouring the internet, I found a post informing me that on 64 bit machines, the install will falsely report it completed successfully and fails to update the machine.config. To resolve it advised adding the following:

to my existing file (C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG), since I’m on a 64 bit box, I also added it to the 64 bit version (C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG).

Did an iisreset, same error, more hair pulling. I downloaded various other things from IBM’s website all of which promised to hold the key. Eventually, I finally find that what I need is DB2 Express-C (db2exc_972_WIN_x86_64.zip). As soon as that got installed, things worked just peachy, and both machine.configs were properly updated.

Here’s my big complaint: when I went and looked at an existing working dev environment (my desktop), Add/Remove Programs said only “IBM Data Server Client – DB2COPY1″, which is exactly what the other programs I installed said. So each time I spent hours looking for some possible setting that was missing, only to find there was no mythical setting, IBM just couldn’t be bothered to put in different names for their installed products. If the Add/Remove Programs entry had instead included “Express-C”, I could have gotten both machines installed with their dev environments ready to go in under an hour. Fortunately, on the new installs, it appears that there is now an entry for this item, so if I ever manage to forget all this, I will know what I need.

Serendipity to WordPress – Changing table prefix

Jon — Thu, 17 Jun 2010 17:00:14 +0000

While this isn’t strictly part of the migration process from S9y to WordPress, I decided to take some advice I read on the net and change the prefix for WordPress tables. Most use this feature for when they have to share a database, but the suggestions I read said to do it to help prevent from SQL injection hacks. Basically the majority of these injections presume a default of ‘wp_’ prefix.

I made this after install very simple by going in MySQL and running RENAME TABLE `wp_posts` TO `prefix_posts` against each table (where “prefix_” was the new prefix). After changing it in MySQL, I changed the wp-config.php line of $table_prefix = ‘wp_’; to read as my new prefix. I popped up to the web and the blog worked fine. Except… I couldn’t access the administrative interface.

You do not have sufficient permissions to access this page.

LIAR!!! What the hell? Yes I do. I did 10 minutes ago and I should now. I tried my other (administrative) users, same problem. This was quite displeasing to me. After a little googling about, I found out that the answer is that the `meta_key` prefix of ‘wp_’ (in `wp_usermeta`) and certain values in `wp_options` are also dependent of this prefix value. Fortunately it is really easy to fix:

UPDATE `PREFIX_usermeta` SET `meta_key` = REPLACE( `meta_key` , 'wp_', 'PREFIX_' ); -- Change PREFIX_ to your new prefix.
UPDATE `PREFIX_options` SET `option_name` = 'PREFIX_user_roles' WHERE `option_name` = 'wp_user_roles' AND `blog_id` = 0; -- Change PREFIX_ to your new prefix.

Execute those two lines of SQL (after you’ve replaced it with the proper prefix), and you’ll be ready to rock and roll again. This is one of those odd little bits that they don’t explain anywhere in the manual – probably because most people don’t use anything other than the defaults… which brings us right back to the security concern (i.e. easy to guess/default password = bad).

Having keys in tables change because the table prefix is different is one of the stranger things done in a web application that I’ve worked with. I can’t really think of a reason to do this, but I’m sure the developers had a good reason (as strange as it might be). Fortunately this problem is easy enough to fix, but it certainly is frustrating when your admin user gets “You do not have sufficient permissions to access this page.” and you know better.

DB2 LUW vs zOS: Selecting from nested subselect

John — Wed, 17 Feb 2010 18:00:00 +0000

SQL0104N An unexpected token “” was found following “”. Expected tokens may include: “CORRELATION NAME”. SQLSTATE=42601

This was the error that I got while attempting to execute a stored procedure under DB2 v8.1 for z/OS. Being quite confused about it, I googled for the answer. I didn’t find one, but I did find this google groups post which made mention of it.

Basically, the situation was that I had

SELECT COUNT(*) FROM
(
SELECT …
UNION
SELECT …
)

And while that works just fine under LUW, z/OS doesn’t like it. The simple solution is to add “AS TBL_1″, or any other name to the parenthetical subselect, which I have done below. Both commands work just fine in LUW, but if you are working under z/OS (or at least version 8.1) you will need to use the bottom example.

SELECT COUNT(*) FROM
(
SELECT …
UNION
SELECT …
) AS TBL_1

In MySQL: x^y != x raised to the y

John — Tue, 18 Nov 2008 01:05:24 +0000

As the title states, the caret (^) is not used as an exponent in MySQL. I’m not certain what exactly it does (and couldn’t find any documentation after a quick search), and would love to find out what its purpose is.

I ran into this problem today when I noticed that MySQL’s math results (using ^) didn’t match my own. After triple checking my own math, I added lots of parens and still got nowhere, so I checked the Operator Precedence and sure enough it listed the caret (^) as falling between “*, /, DIV, %, MOD” and “- (unary minus), ~ (unary bit inversion)”. This made me think that surely I have a typo in my code somewhere since if the operator is mentioned it should be supported. WRONG.

Convinced that something had gone horribly awry I began to look through the other math function available and switched to using POW and SQRT which instantly remedied the problem.

After getting my equations working I began to try to find more information on the symbol that caused me so much frustration. Alas, as mentioned above, I could find no specific information, other than some hints that it might be used for RegEx or as XOR, though after running the query below, I remain unconvinced.

SELECT 1^0, 1^1, 1^2, 1^3, 1^4, 1^5, TRUE^FALSE, TRUE^TRUE, FALSE^FALSE, FALSE^TRUE

1^0 1^1 1^2 1^3 1^4 1^5 TRUE^FALSE TRUE^TRUE FALSE^FALSE FALSE^TRUE

1 0 3 2 5 4 1 0 0 1

1^0	1^1	1^2	1^3	1^4	1^5	TRUE^FALSE	TRUE^TRUE	FALSE^FALSE	FALSE^TRUE
1	0	3	2	5	4	1	0	0	1

From the “all-your-databases-are-belong-to-me” department…

John — Fri, 21 Sep 2007 19:02:00 +0000

I figured the best way to start this spot is with 4 ways for absolutely anyone to make their DBA’s life easier.

Never start a conversation with “I just need this one thing, really quick”. This rule can be expanded to replace one with any given number.
1. Reasoning: You are not a DBA and most likely do not know what else the DBA is working on, it is much better to ask, “I have a couple things I need from you; do you have time to go over them now?”
Don’t touch the development database(s). EVER. Seriously. Your DBA is in charge of monitoring changes to the database(s) and making sure they (eventually) get pushed to production. Unless you are given explicit permission by the DBA (and no, their higher ups or underlings do not count) do not attempt to modify ANY schema EVER. Doing so can cause serious problems during an upgrade cycle as everyone tries to figure out why functionality that worked well in development is going haywire in production.
Don’t touch the production database(s). EVER. I really shouldn’t even have to state this rule given its predecessor. And yet, I have; why is that? Because some people seem to think it is alright to do whatever they want to a production database, since it is, well, in production.The logic, as I have had it explained to me is as follows: “Once [the database] is in production, what do you care what happens to it? You don’t have to monitor changes to it; you just have to make sure it gets backed up properly, so that if a customer breaks something we can roll back.”
This is a serious problem.

Let’s use a little example: A customer calls in and requests some changes. Bob, being the genius that he is, realizes that he has access to the production database of the customer in question (for some reason known only to IT) and decides that in his infinite wisdom he will make the changes to the customer’s database and drop a line (something akin to: “FYI: I made some changes to database xyz”) to the DBA afterwards.

There is nothing more frightening to a DBA to see than an email from someone who thinks they know what they are doing than that. In the aforementioned example, Bob has not actually performed the changes to the correct database. He has in fact changed another customer’s database. This other customer is now quite upset that something has gone horribly awry and demands a fix. The DBA now has a choice to make:
1. Talk with Bob and try to pin down exactly what he did. Sadly, this choice often leads to the following conversation:
  DBA: You made changes to the wrong database. I need to know EXACTLY what you did.
  Bob: Oh you know, just this and that. Added some columns, dropped some columns that sort of thing. Don’t you have monitoring software to record stuff like that?
  DBA: Let me get this straight, you made schema changes and didn’t bother to save the script?
  Bob: What’s a script?
2. Restore from a previous backup. This of course causes the customer to lose out on any data from after the backup was performed, but is much faster to do. If it is an important customer, then the DBA can script some of the data over from whichever tables they were using, however this will take time. This of course results in angry customers. Plus, the first customer still hasn’t had his changes made.
Script everything. It doesn’t matter if you are ignoring 2 and 3, or if you have been given explicit permission from the DBA. If you make modifications to a database, especially for schema, script it all out. Your DBA will thank you for it. It makes things so much easier.

Lastly, just for you IT folks out there, the number one way you can make your DBA’s life easier right this very second.

Revoke access to the databases from EVERYONE, but the DBA.
Yeah, I know, not going to happen, but a DBA can dream, right?