findspell and cast X do not work for all chars all zones after recompile

[causticsand]

Required SQL's from git repository are sourced.
database shows all spells and spell information.
showspell returns zero's or nothing for spell info
cast X returns nothing and nothing is cast
log shows that spell was attempted to be cast.
used command: #findspell 30 (target=NONE)
spells_en and spells_us are in the server run directory
I'm at a loss here as to what I didn't do.

[causticsand]

I get "spell ID out of range" on a new character. There are no mobs/npcs in the tutorial(all I've checked)
I copied spells_* to the /server directory from an untouched HoT client install
I'm willing to troubleshoot so my kids can get back to turning all the PoK npc's into raptors :grin:

[KLS]

Usually when spells wont load correctly it's because shared_memory hasn't been rerun since a code or database change.

Spells are loaded from the database, specifically the table: spells_new and then are shoved into a shared_memory segment that all the zones open. Also sorry, spell support gets less traffic than the other support forums so we check it less often.

[causticsand]

Thank you for posting, KLS. In this case, it appears the user wasn't telling the truth. I *thought* I had sourced in all required files, but I think the query I was using only sourced in 2014*. After carefully making sure to use the ones with 2013* and forcing them to go in ignoring errors, it seems to have worked. I quickly made a backup when everything was running smoothly.

For any future readers, the required sql's are in ../eqemu/utils/sql/git/required
I sourced them in with these commands:
$ mysql -u eq -p --force eq < 2014*.sql
$ mysql -u eq -p --force eq < 2013*.sql

The '$' means regular user not a priviliged user and the 'eq' before the '<' is the database that the sql files were being sourced in to. There were errors when sourceing. This is why I ran it a couple times. It seems as though some columns that were needed already weren't created until further down in the importing. By this I mean that, let's say the imaginary SQL file 2014_h.sql had a column it created that 2014_g needed. Running the above commands multiple times with the force option made sure that any columns that needed to be made, were, and were populated on the next run-through.

Thanks again, KLS, and I appreciate all the hard work you guys do!