GrapeApe

Are you running it on Windows or Linux?

There are links to installation guides for both platforms in these forums, try a search.

Deleting the table and restarting the module will re-create the correct table structure, so this should work fine for you.  Unfortunately, you lose all your stored gear as the table will start empty.

This is what i ended up doing and it is working fine now. Since i already lost all stored items from the new version it didnt really matter to delete it and rebuild .

I've heard from others that the table isn't getting built via buildtable, you can use the following to create the table manually:

CREATE TABLE `pw_containers` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `tag` varchar(32) NOT NULL default '',
  `name` varchar(64) NOT NULL default '',
  `timestamp` timestamp NOT NULL,
  `PCid` varchar(128) default NULL,
  `sItem` varchar(255) default NULL,
  PRIMARY KEY  (`id`),
  KEY `tag_name_idx` (`tag`,`name`)
)

I have changed the sizes of the tag and name field as the key was too large and was giving an error with the sizes at 255 each. If your table built ok you prolly don't need to change anything, you can use the above as a guide to double check.

GrapeApe

ALTER TABLE `pw_containers` ADD `sItem` VARCHAR( 255 ) ;
UPDATE `pw_containers` SET sItem=CONCAT('#I#', itemResRef,'#', stack,'#',identified,'#0#/I');
ALTER TABLE `pw_containers` DROP `itemResRef`, DROP `stack`, DROP `identified`;

couple of questions:
I am using mysql 4.1

1. alter table is not a valid SQL command so i had to hand enter "sItem" dose this have a default value of "null" and or allow "null"
2. UPDATE `pw_containers` SET sItem=CONCAT('#I#', itemResRef,'#', stack,'#',identified,'#0#/I'); There is no identified colum in this table.


As of right now the lockers are not working, any item put into them will dissapear.


im trying to delete the table and reboot server to see if it gets rebuilt correctly.

1. ALTER TABLE is an SQL command valid in all standard SQL DBMSs and therefore is usable in MySQL v4.1 (same version I'm using) as well as any mysql version you could possibly download and install. And the way the command is layed out should automatically set the column to 'null' allowed and default. You could try taking out the backticks (`) and see if that has any bearing. Are you using a windows sql install? And are you sure your mysql user account has rights to alter tables?

2. I had deleted the columns already when i rewrote this line for the comments in ff_buildtable that I passed to Horred. So, check the column names and make sure they match the 3 fields in there already.

Deleting the table and restarting the module will re-create the correct table structure, so this should work fine for you. Unfortunately, you lose all your stored gear as the table will start empty.

Are they new or old characters? Or both?

Maudib:

Only servers that were running a pre-release of v10 need to update the pw_containers table, servers upgrading from v9 or earlier don't need to as the table isn't there and get's created by the ff_buildtable script for them.

But, here are instructions/SQL to update your table and allow your users to keep their items in the container's they're in:

ALTER TABLE `pw_containers` ADD `sItem` VARCHAR( 255 ) ;
UPDATE `pw_containers` SET sItem=CONCAT('#I#', itemResRef,'#', stack,'#',identified,'#0#/I');
ALTER TABLE `pw_containers` DROP `itemResRef`, DROP `stack`, DROP `identified`;

Reminder: above is only for the half dozen test servers that had pre-release v10.

Infernus:

Sounds like you're trying to update CnrBoolBuildRecipeDatabase val=1 for table cnr_misc table. If you don't have that table then something has gone wrong with the sql build scripts or nwnx's access to the db.

GrapeApe