After a lot of tinkering around, I've found the problem in the above code. Well, not as much "found" but more like "stumbled upon". Removing the "id" column, all seems to work well.
The following code:
$jal_db_version = "1.0";
function jal_install () {
global $wpdb;
global $jal_db_version;
$table_name = $wpdb->prefix . "liveshoutboxzz";
if($wpdb->get_var("show tables like '$table_name'") != $table_name) {
$sql = "CREATE TABLE " . $table_name . " (
time bigint(11) DEFAULT '0' NOT NULL,
name tinytext NOT NULL,
text text NOT NULL,
url VARCHAR(55) NOT NULL
);";
require_once(ABSPATH . 'wp-admin/includes/upgrade.php');
dbDelta($sql);
add_option("jal_db_version", $jal_db_version);
}
}
register_activation_hook(__FILE__, 'jal_install');
Seems to work fine, creating the table, returning no errors - which is odd, taking into account that the code I've mentioned earlier works when executed directly (in PhpMyAdmin, not in WordPress). Can't tell if this is a WP 3.0 bug.
I've tried redwallhp's of commenting out this line:
require_once(ABSPATH . 'wp-admin/includes/upgrade.php');
But no success either.
I'm baffled, because although in this case, when the plugin is activated and error occurs, the table is CREATED anyway. And the worst (or best) is that the plugin DESPITE SHOWING AN ERROR ON INSTALL, seems to work perfectly.
Although my problem was solved, I'm leaving this as unsolved because it just doesn't make any sense. dbDelta() seems to be working fine (and no where it's included in the 3.0 changelog), yet something isn't right.