Today I was trying to edit the value in a table cell through the query browser in Microsoft SQL Server Management Itudio and I kept getting the following error:

Data has changed since the Results pane was last retrieved. Do you want to save your changes now?
(Optimistic Concurrency Control Error)
Click Yes to commit your changes to database anyway.
Click No to discard your change and retrieve the current data for this row.
Click Cancel to continue editing.

I would click “Yes”, and get another error:

No row was updated.
The data in row X was not committed.
Error Source: Microsoft.VisualStudio.DataTools.
Error Message: The row value(s) updated or deleted either do not make the row unique or they alter multiple rows(N rows).
Correct the errors and retry or press ESC to cancel the change(s).

I was killing myself trying to figure out what was wrong. I was the only person working on the database, so the data wasnt being changed behind my back.

After an hour on goolge I came across a Microsoft tech article for MS SQL 2005, http://support.microsoft.com/kb/925719

It stated the issue could occure from one of the following conditions:

• The table contains one or more columns of the text or ntext data type.
• The value of one of these columns contains the following characters:
• Percent sign (%)
• Underscore (_)
• Left bracket ([)
• The table does not contain a primary key.

I double checked the table I was working on and realized it didnt have a primary key. It must have gotten dropped in the data migration from MS SQL 2000 to MS SQL 2008. A simple right click, set primary key and my problem was fixed.

Verify the primary keys! It’s a simple fix to a head breaker of a problem. I hope someone finds this and it fixes their issue.

Today I ran into a situation where I had forgotten the password to my development instance of phpBB 3. I was stuck in a situation were I needed to reset the password. I had full admin access to the database, so changing it there wouldn’t be the problem. The real problem is that phpBB uses its own password hashing, not MD5.

In a work around, I created a new user and used the password “123456″ looking at the database , in the users table of the phpBB install. I saw the “user_password” field was “e10adc3949ba59abbe56e057f20f883e”.

I then changed my admin accounts user to the same string, “e10adc3949ba59abbe56e057f20f883e”.

I went to the phpBB login screen, fillled out my username, and entered the password “123456″… BINGO! it worked.

So to save you the work. You can follow what I did or just use these hashes to reset your own password:

Hash: e10adc3949ba59abbe56e057f20f883e
Password: 123456

Hash: $H$9Ae3Uk.ECdWW5ya13M4ErWhr4c.761/
Password: password

I hope this helps someone else out there.

It doesn’t matter what application your working with, losing your password is always a pain in the ass. Luckly if you are working with wordpress (man, I blog a lot about wordpress these days), on your server and you have access to the MySql database, resetting your password manually is a snap.

• Login to your PhpMyAdmin
• Select your WordPress database and click on the “SQL” button to open the SQL query window.

• Paste the following code in the window textarea. (Don’t forget to modify the password and username before executing it)

UPDATE ‘wp_users’ SET ‘user_pass’ = MD5(‘PASSWORD’) WHERE ‘user_login’ =’admin’;

That’s it! Your password has been reset, and you should be able to login to your wordpress admin area once again.

Recently I was backing up a large MySql database (several hundred megabytes), using the awesome MySqlHotCopy script, when I started getting the following error:

DBD::mysql::db do failed: MySQL server has gone away at mysqlhotcopy line 528.

I have no clue what that error means. mysqlhotcopyworked great on all of my other smaller databases. I did a little searching on my old friend google, and after sniffing around a bit, I came up with a resolution to the problem… the script was timing out, so I just had to increase the allowed time in the /etc/my.cnf file.

Here are the steps I took

pico /etc/my.cnf

add these lines to the file:
interactive_timeout = 3600
wait_timeout = 3600

save file

/etc/init.d/mysqld restart

I ran mysqlhotcopy again, and everything worked and the backup was made.

Sometimes I do my best programming when I’m tired. Don’t ask me why, I just do. It’s a skill I picked up in college.

Being tired and producing good code wasn’t the case last night. I was trying to use the sprintf PHP function with a SQL “Like” statement. I made some dumb mistakes that tripped me up for a while. Hopefully someone out there will find this post and help them not make the problems I made, sleepy or not!

Normally the LIKE is used in mysql like this:
SELECT name FROM users WHERE name LIKE 'J%';

That would get all names including: Josh, Jason, Jimi, etc.
In a SQL Like statement the % is a wild card, so the command is to match everything starting with “J”

Now when you use the sprintf() function it looks kind like this:
$query = sprintf("SELECT name FROM users WHERE name='%s'", $searchString);
The %s will be replaced with the value of $searchString

Trying to combined them is where I had some problems….

At first I tried to do something like this:
$query = sprintf("SELECT name FROM users WHERE name LIKE'%s'", $searchString);
didnt return what I was looking for at all, it had no wild cards in it!

Then I tried this:
$query = sprintf("SELECT name FROM users WHERE name LIKE'%s%'", $searchString);
didnt work either, this time it threw errors

But this worked great
$query =sprintf("SELECT name FROM users WHERE name LIKE '%s'", $searchString . "%");

So the moral of the story is, if you want to use a SQL Like statement, appent the wildcard for the Like statement to the string to be inserted by the sprintf funtion.

SELECT *
FROM tableName
WHERE conditions
ORDER BY Rand()

Using the Rand() function will randomly select the rows. You can limit the number of rows returned by using the LIMIT command

I ran the mysqlhotcopy command as root, and was greeted with an error similar to this:
Invalid db.table name 'foo.foo`.`bar'

um, no…. this table exists

I have cpanel installed on my server, a lot of server do. cpanel does updates to many application, mysqlhotcopy is one of them. It looks like my version of mysqlhotcopy was updated to 1.22, and there is some major problems with mysqlhotcopy 1.22.

I did some googeling and I found some people talking about the problem. I even found a quick patch for the problem. The problem comes from a host adding the username and an underscore before a database name (example: “username_databasename.table“). mysqlhotcopy only looks for databasename.table

The following patch instructions will fix mysqlhotcopy 1.22

• Open the perl script for editing. It is located at /usr/bin/mysqlhotcopy
• find the following subroutine
  

  sub get_list_of_tables {
  my ( $db ) = @_;

  my $dbh = DBI->connect(“dbi:mysql:${db}${dsn};mysql_read_default_group=mysqlhotcopy”,
  $opt{user}, $opt{password},
  {
  RaiseError => 1,
  PrintError => 0,
  AutoCommit => 1,
  });

  my @dbh_tables = eval { $dbh->tables() };
  $dbh->disconnect();
  return @dbh_tables;
  }

• look for this line (mine was link 821):
  

  my @dbh_tables = eval { $dbh->tables() };

• immediately after that line add the following:
  

  map { s/^.*?\.//o } @dbh_tables

Here is my patched subroutine:

sub get_list_of_tables {
my ( $db ) = @_;

my $dbh = DBI->connect(“dbi:mysql:${db}${dsn};mysql_read_default_group=mysqlhotcopy”,
$opt{user}, $opt{password},
{
RaiseError => 1,
PrintError => 0,
AutoCommit => 1,
});

my @dbh_tables = eval { $dbh->tables() };
map { s/^.*?\.//o } @dbh_tables;
$dbh->disconnect();
return @dbh_tables;
}

After I applied the patch, everything was back to working order.

Some people have other approaches that would work also, like downgrading mysqlhotcopy all together.

Personally, I think adding one line of code wasn’t that big of a deal to fix the program

I took a few minutes to run some of my own test using two of the largest text fields on the notPopular.com user profile table. I wanted to check out the results of a FULLTEXT search versus a LIKE query using real data in my database.

First I did a search using the LIKE clause looking for “xdeathstarx”


SELECT *
FROM profiles
WHERE approved =1
AND
(interests_general LIKE '%xdeathstarx%'
OR
interests_music LIKE '%xdeathstarx%')

Showing rows 0 – 29 (119 total, Query took 0.0763 sec)

The query was fast, and took under a second to run

Next I created a FULLTEXT index on the “interests_general” and “interests_music” fields. It was really easy to do.


SELECT *
FROM profiles
WHERE approved =1
AND MATCH (interests_general, interests_music)
AGAINST ('xdeathstarx')

Showing rows 0 – 29 (119 total, Query took 0.0016 sec)

Talk about fast! it took 0.0016 seconds

lets compare the differences:
LIKE statements : 0.0763 sec
FULLTEXT search : 0.0016 sec

hands down the FULLTEXT search won, it was about 50x faster. If that isn’t instant results, I don’t know what are. Sure there will be more disk space used on the FULLTEXT index, but disk space is cheap, CPU cycles aren’t.

This makes me want to look more into optimizing the queries I am planning on using for the ever elusive notPop 2.0