Table privatemsg_block_user doesn't exist

i have the same issue

I have the same with latest build (17-Aug)

chx added it three days ago.

I *just* downloaded it and get this error.

The install file needs to be updated: The table 'privatemsg_block_user' won't get updated but only be installed for user doing a fresh installation. So, everybody who is already using privatemsg will run into the same problem.

I still don't know much about creating patches and CVS, so please excuse me posting the fix here. Anyway, for those needing to fix the bug immediately, run following query in MySQL (worked for me):

CREATE TABLE privatemsg_block_user (
            author int unsigned NOT NULL,
            recipient int unsigned NOT NULL,
            PRIMARY KEY (author, recipient)
          )  /*!40100 DEFAULT CHARACTER SET utf8 */")

As far as I understand, following entry should be appended to the next update of the privatemsg.install file :

function privatemsg_update_4(){
  $ret = array();
  if (!db_table_exists('privatemsg_block_user')) {
    switch ($GLOBALS['db_type']) {
      case 'mysql':
      case 'mysqli':
        $ret[] = update_sql("CREATE TABLE {privatemsg_block_user} (
            author int unsigned NOT NULL,
            recipient int unsigned NOT NULL,
            PRIMARY KEY (author, recipient)
          )  /*!40100 DEFAULT CHARACTER SET utf8 */");
        break;

      case 'pgsql':
        $ret[] = update_sql("CREATE TABLE {privatemsg_block_user} (
            author int unsigned NOT NULL,
            recipient int unsigned NOT NULL,
            PRIMARY KEY (author, recipient)
          )");
        break;
    }
  }
  return $ret;
}

Oops, sorry for the typo in my last post: The Query for MySQL has to be as follows:

CREATE TABLE privatemsg_block_user (
          author int unsigned NOT NULL,
          recipient int unsigned NOT NULL,
          PRIMARY KEY (author, recipient)
        )  /*!40100 DEFAULT CHARACTER SET utf8 */

You're right, updating doesn't add the table. If you apply this patch, you'll get another chance to update, and this one will add the privatemsg_block_user table.

Let us know whether it works.

@chx: I'm confused about the pgsql version of privatemsg_update_3():

1. Why does it need a foreach?
2. Is the three-step updating really needed? We're attempting to do the same thing in one step for Subscriptions...
3. OTOH, we did specify a default of 0 for mysql...

It turns out there's a lot more work to be done...

Fix http://drupal.org/node/163908 [')' instead of '('].

Here's a list of the recent updates:

• In 1.5.2.4.2.2 (August 1) the privatemsg_mails table was introduced.
• In 1.5.2.4.2.3 (August 13) it was renamed to privatemsg_mail_edit, but only for MySQL.
• In 1.5.2.4.2.4 (August 15) privatemsg.subject was changed from varchar(64) to varchar(256), but only for MySQL.
• In 1.5.2.4.2.5 (August 16) the infamous privatemsg_block_user table was added.

All these changes were done without providing an update() function.

The attached patch replaces #7. It fixes all these inconsistencies and provides an update() function to make the necessary changes to the database.

@chx: varchar(255) seems to be more popular than varchar(256), so I chose the former. Should privatemsg_archive.subject also be changed to varchar(255)?

Hi,
I tried the patch twice, but received a bundle of error messages (see attached screenshot). Both times with the same errors.

First time, I deleted the table privatemsg_block by hand and updated after patching the install file.
Next time, I deleted all tables and entries in the system table, then installed a fresh version of privatmsg 1.8. Afterwards, I installed the patched 2.0 version.

Please let me know if I should try/ test something else.

Thank you for your test and report. Please try this slightly modified patch instead.

With this new patch you should be able to upgrade successfully from your current state (after producing the error messages that you sent, with or without deleting the privatemsg_block_user table), IF you set the schema_version for privatemsg back to 3 in the system table, so that Drupal will run the privatemsg_update_4() function.

You should also be able to upgrade cleanly from 1.8 now, and I'd appreciate it, if you could give this a try as well.

BTW, uninstalling Privatemsg (after disabling it) should give you the same (or even better) result as manually deleting the tables and records from the system table.

Is anyone out there using PostgreSQL? It would help me tremendously if you could try out this patch and report back.

Oops, seems like I always need two uploads. Forgot to remove the carriage return characters...

Hi Salvis,

thank you for the hint with the uninstall feature - I really must be blind to ignore the uninstall button on the module page...

I tested both ways you asked me to do with following results (pictures say more than words, therefore I made some screenshots again):
- After setting back schema to 3, the update 4 ran succesfully (p. 1).
- Now I tested the new (for me ;o) ) uninstall feature. The privatemsg and variable tables were cleaned, only the system table entry was still there after uninstall. (p. 2).
- I cleaned it manually and installed version 1.8, then I updated to v.2.0 with the patched install file: The database update screen offered me update 3 (p. 3) and all updates were successful (also update 4, see p. 4).
- Now, I activated the mail_edit module and got a warning (p. 5) due to a missing uninstall function in the install file. I deleted this existant table and hit "Save Configuration" again. The installation now ran without problems and the table was created.
- Everything looked fine, except one small thing: The privatemsg module threw a warning that the column 'type' in the privatemsg table is missing (p. 6).

Thanks for your support.

Hi olio,

Thanks again for the detailed report. I'll open a different issue for mail_edit and focus on Privatemsg here.

chx has updated privatemsg.install to 1.5.2.4.2.7 three hours ago (5.x-2.x-dev will be updated by the packaging script within a few hours, or you can take the file from CVS).

I rerolled the patch for 1.5.2.4.2.7 and added the missing privatemsg.type column, and I've also fixed $db_prefix support. I hope this will be the last iteration... Would you take another stab at it, olio?

Is there anyone using PostgreSQL?

Hi Salvis,

I tried the patch and called the db-update page, where an syntax error message appeared (p. 1: "Parse error: syntax error, unexpected '{'... "). The error disappeared after I added a missing closing bracket ')' to each instance of '(db_prefix_tables(...' in the install file (p. 2).

By the way, I'm not sure, but as far as I understood, there's no need to add curly brackets because the function function db_prefix_tables() adds them automatically (http://api.drupal.org/?q=api/function/db_prefix_tables/5). After deleting those and adding the missing closing brackets, I could update without errors.

O.k., now everything seemed to be fine: No errors while calling the pages list, compose, contacts, manage folders.
Until I composed and sended a private message - where drupal showed me a white screen (and the URL was still 'privatemsg/new', see p. 3)! But the message was correctly sent and received (p. 4 and 5) and also there was no log entry (p. 6).

Hi olio,

It turns out that db_table_exists() does it all by itself, without the db_prefix_tables() nor the curly braces. It was a long ride, thank you for pulling through!

I'm sure there are still a few bugs in privatemsg.module. Please open up a new issue regarding the white screen — chx will have to take care of that. My goal here is to fix the database issues, so that we can at least install Subscriptions and Privatemsg. chx has an assignment to develop new features for both modules, and he's working on a very tight schedule. He assured me that he'd be switching to bug fix mode RSN, and if we can already get rid of the database issues now, he'll be able to concentrate on actual bugs.

Would you also try the http://drupal.org/node/169703 patch for mail_edit?

Thanks again!

Hi Salvis,

o.k., I will open up an issue for the white screen problem.

I began with a fresh install of the patched version and got some warnings.

warning p. 1:
- On line 158 (after patching), I think the table name should be changed to 'privatemsg_mail_edit' instead of 'mail_edit'.

warning p. 2:
- On line 49, an entry 'description varchar(255) NOT NULL' made the user warning disappear.

warning p. 3:
After this warning I uninstalled privatmsg again and installed an unpatched version 2.0.
The same warning (p. 1) appeared again. So I decided to change line 158 in order to continue with testing your patch:
- On line 158, I combined the two 'db_query("INSERT INTO {privatemsg_mail_edit}...' into one. Although I'm not sure if this has other side effects, the warnings disappeared and I could use privatemsg normally (that means up to the white screen I described yesterday).

Now I applied the patch and ran update afterwards:

warning p.4:
Duplicate entry for column name 'type'.

Beside this, the patch worked well and I could use privatemsg.

I will continue now with the test of your mail_edit patch.

Hi olio

I'm sorry about the delay.

warning p. 1:
- On line 158 (after patching), I think the table name should be changed to 'privatemsg_mail_edit' instead of 'mail_edit'.

No, I don't think so. The mail_edit table belongs to mail_edit, and the privatemsg_mail_edit table belongs to privatemsg. The two INSERTs were added by chx.

You need to install mail_edit before privatemsg, then the p.1 message should go away.

Your other tests are not valid because of your change.

I thought I'd wait for chx to post an updated .info file to advertise the prerequisites, but I'm breaking down and will post a patch...

It just dawned on me that the two INSERTs, which chx recently added to privatemsg_install(), also need to go into privatemsg_update_4().

So, here's my last iteration.

P.S. I'll add the .info patch (to enforce the depencencies on mail_edit and Subscriptions) to http://drupal.org/node/168470 shortly. Apply that patch before enabling Privatemsg to see it in action.