eq2-updates.sql error

[Cynnar]

I have ran across an error when trying to patch the database.

18:58:40 E Database : Error running MySQL queries from file 'eq2-updates.sql' (1050): Table 'bot_appearance' already exists

What I think has happened is that I sourced in the latest dev_db before I patched the database using the patcher. What I done was removed the create table from the eq2-updates.sql and ran the query. It had a few problems since some things were duplicates, and I just removed those lines and ran again until I got through every line.

Is there a way we can fix this so it will not happen in the future? Maybe a create if not exist instead of just create?

[Jabantiz]

On new tables we can add a drop before the create. But in general the patcher should always be ran before sourcing in the dump as the dump does not provide data for the table_versions table.

[Cynnar]

Yeah I wasn't thinking. I now have a sort of messed up db now. I may need to nuke it and start all over. For some reason the live client is now crashing when trying to log in. I know my opcodes table is all a mess now, but I can't get the patcher to re download it.

[tyrbo]

Mine is also messed up and has made it a pain to get updates, so I've been manually running CREATE TABLE calls from the updates file as needed.

Would love a dump of the latest table version table.

[Cynnar]

I will post as soon as I patch.

[Cynnar]

Strange question, but how do I turn on and off the command line window output from the patcher. I know that there is a way as I did turn it off and now I don't get output when patcher is patching. I just can't remember what I done to turn it off.

[tyrbo]

Probably in log_config.xml.

There's also

Code: Select all

#autotableverbose displays detailed information about the updates; options=true or false
autotableverbose=false

[Jabantiz]

Should be in the logs config file under patcher.

If you want to nuke the table and redownload it just delete its entry in the table_versions table, it will act like you don't have the table and redownload everything. opcodes does have a drop in front of it so it will nuke the table you currently have.

[Cynnar]

autotableverbose=false
Yeah that is it. I knew I had changed something.

If you want to nuke the table and redownload it just delete its entry in the table_versions table

Thanks that is good to know. I am restoring a backup I done just before I switched from MySQL to mariadb. I don't think I have added anything to my local that is not already on the svn, but it is a gamble.

[Jabantiz]

Just went through the patcher db and added a drop before every create, only about 4 tables were missing them, most of them were the bots tables I committed

[Cynnar]

Just went through the patcher db and added a drop before every create, only about 4 tables were missing them, most of them were the bots tables I committed

This should help on any future problems like some bonehead sourcing in the db before updating it? Cause you know I'm not the only bonehead.

[John Adams]

On new tables we can add a drop before the create. But in general the patcher should always be ran before sourcing in the dump as the dump does not provide data for the table_versions table.

btw, if I ever finish the DB Auto-Updater query tool, it will always put a DROP statement before a CREATE if one is submitted without one. I am assuming if you are CREATEing something, it must not be there or you would have submitted an ALTER.

Also, couldn't Cynnar have just deleted or changed the version in table_versions to force an update? Or was it because there wasn't a DROP that it would never work right?


Edit: Oh, just finished reading the thread. Jabantiz laziness strikes again