5.2 databases
 

I've tried almost every db out there that say they work with 5.2
and yet all of these posted DB's none of them work by sourceing them freash into a new eq DB.

I can get 5.2 dev DB to work fine but withanything sourced in or sourced by itself nothing works and yes I droped the DB and resourced about 50 times.

anyone else havething this problem or is it just a MYSQL problem ??

Post a more detailed description of your trouble, like what's happening when you start world.exe or when you try to connect.
btw, have you added a user to log with ?

yes the char select screen loads fine.
 

Yes im able to create a char and everything loads fine.
the problem is when trying to enter a zone.
world.exe reports :
Received unknown opcode: 0x02d2 size:0 bytes
now it was explained to me that this has nothing to do with the DB
but is probbly client releated.
it makes no sense tho because
Im able to log in to any other server in the list fine also
im able to log into my own server useing the
dev DB prebuilt with 5.2.
the problem seems to be that
when I install any other DB built for 5.2 zone exe don't like it
I have installed 5.0 and 5.1 fine and they run perfectly.
minus the dev bugs.
im pretty much baffeled as to why this is happeneing.

Just any fyi most the current db release's have been full database's and do not need the db.sql and update0.5.2.sql.

Just trying to help.

you are right
 

Yes I tried the both ways just for kicks.

I can't get any of them to work it's wierd.
I do know I can get db.sql to work fine so im not sure why im having such a hard time with all these other db's.

I deleted everything and started fresh and nither way works.

I rember from 4.x That that was just a debug message and no real error occured. It didnt not crash anything or do anything at all other then spamm World with that everytime someone logged in or zones. I think its still that way with 5.x

I've been seeing that unknown opcode for days. It hasn't caused anything to noticably work incorrectly (from what I've seen).

Sdabbs: DBs are a little frustrating if you don't know what you're getting into... they hold tons of data and one wrong move can cause the entire db to not work. I'll always suggest TCS & Team's MWnpcmovDBs, as the members of the team that put this db together interact with higher members of the eqemu team and make fixes according to code changes. Although there are other fine DBs out there to check out, I suggest MW_051_052_alpha3.2 (if using 5.2) or MW_052_053_alpha1 (if using any build above 5.2 official).

Where can these be found? Well you can check the forums, or log into IRC and join #npcmovdb (on eqemulator.net IRC). We always list the latest DB for release in there.

All of the MWnpcmovDBs are standalone complete DBs; IE, never include other DB files into it (eg, the 5.2 update, etc). Each DB has all the updated values it needs (we did the work of getting it together so you don't have to). Source the DB in a clean mysql database container (ie, 'eq' or 'eq52') and then just run it. No further configuration should be required (besides eqemu configuration... make sure all of your .INI files are correct).

The DB works, you just need to be real careful and follow all of the setup guides that have been made available.

well thanks
 

I thinks it's a MYSQL problem but im unable to isolate it.
next step is to uninstall MYSQL completely and rebuild from scratch.
I have already sourced all those with a clean DB and none of them work but like I said DB.SQL works fine.

yes like kroeg said they can crash with the click of a button. They are freaking agonizing to make and make it work but the rewards are perfect.

What I did was, I had 2 bugs, one a crash in 3 specific zones, and an item disappaer, i fixed item bug, but i realized that the crash for zones was because i f-ed up the quest database on an npc in that zone. I just erased it and it started working again. :wink: Check all things that even might not have anything to do with it. like...datarate is sitting on top, you think its latest, you check other things, and you check that and thats it. Cover all bases.

As I say "I Have the Greatest Weapon of All, My Mind and My Logic"

Re: well thanks
 

Myra's is compatable with the current db.sql, what is the error you have been getting?

well...
 

see the first post, im being told it's not db related but that does not explain why i can source the dev released db and not the others it must be something funky in MYSQL.
I deleted the db's and restarted mysql created new db, and then s ource them alone with the same exact results.

also not I can load up 5.0 and 5.1 perfectly. "shrug"

Have you bothered trying to compare the db.sql you claim works, and another db that doesn't work?

Database values change in almost every single release of eqemu... don't be surprised if you find yourself unable to use 1 db for more than 1 release.

Let me recommend a program called SQLyog (www.webyog.com/sqlyog/)

With this program you can visually compare two databases side-by-side, with color syntax highlighting. Use mysql-front 2.5(if you don't know where to find this.. im going looking for mattmeck =P) to edit the values once you understand what changed.

Ok, so at this point ... make note of the syntax that highlights in SQLyog, and open up mysql-front and dump each table one at a time (via .sql files). Make sure to check the "drop table if exists" option, and to uncheck the "create database" option if it is checked.

Once you dump all tables from there, open a mysql command prompt and type the following
(in this step you are going to use the empty db)

mysql -u root
mysql>use emptydb;
Database Changed.
(here you should be sourcing back in the files .sql that you dumped previously)
mysql>source account.sql;
mysql>source anotherdumpedfile.sql;
mysql>source yetanother.sql;

Pull one table over one at a time, and boot the server each time you add a table (this really teaches you what effects what).

If you get a 'column count doesn't match at key 'whatever'', that means the columns you are trying to copy over are off, or in a different order/have different values. To correct this use mysql-front (easy enough to figure out if you take the time to learn the interface... and you should =P )

With so many servers running just fine, you'd have to stop and think that the problem may just be on your end and not have anything to do with whatever DB you decide to use. Make sure mysql is set correctly (big emphasis on mysql here... 99% of the time, the problem is in your mysql configuration).

This may not be an adequate answer, but I have a feeling it's the best you'll get.

best answer yet.
 

well hmm thats what I get for trying to use something that is suppose to be used for 52 and 53 out of the box I suppose.
but this is not isolated to just one db source.
it's more than likely a mysql error since i deleted the db and resourced so many times maybe it got confused or invalid data somehow.
im just going to delete it all and see what happens.
i will keep you updated this is valuable information to someone who is just starting a server and switching versions.
I have not seen an error like this before and it's probbly just one of those winblows errors that i never seen untill now.
you know how confused winblows gets if you use it to much <G>.
athis actually does help and what do you know iv'e actually learned a little more about mysql than i ever wanted to know hehe.
I was really interested if this was just me or if other had this same problem before.

If you are using the 5.2 builds and mw_052_053_alpha1.sql there is a problem in the zone_points table. It looks like the layout in dq.sql is very different than the layout in mw_052_053_alpha1.sql.
All of the fields are there but they are layed out differently. I was having the same problems with unknown opcodes untill i compared the databases and changed the zone_points table layout to match the db.sql layout. Once i did that most of the unkown opcode errors went away. I compared all of the tables and there are a few other tables with minor differences that i think are responsible for the few unknown opcodes i am still getting. The following tables had minor changes.

Start_Zones had the fields bind_id and player_choice missing in db.sql.

Tradeskillrecipe had the field product set as indexed with no duplicates in db.sql.

sharedbank had the field color missing in db.sql.

npc_types had a new field lastname in db.sql.

ground_spawns had the field respawn_timer missing in db.sql.

altadv_vars had the skill_id field set to not indexed in db.sql.

All the rest of the tables appeared to have the same structure and layout. And once i changed the zone_points table most of the unknown opcodes and crashes ended.

ahhhh at last the truth comes out..
 

Thanks Vaelene I thought I was going nuts.

your my #1 hero of the day.