antiroot

Your 'ORDER BY bag,slot' is causing MySQL to do a filesort (which is bad) you can remove the order by completely and it will be faster, but if you really want to sort by those fields create a new index using guid,bag,slot which will get rid of the filesort. Heres some quick tests on my server (note: my database has very little data in it, used SQL_NO_CACHE for testing) (74 total, Query took 0.0029 sec) - No Indexes (74 total, Query took 0.0013 sec) - No ORDER BY (74 total, Query took 0.0014 sec) - With guid,bag,slot index

Can you post additional information, 1) ports you have forwarded on your router 2) type of router (if its similar to any of the ones of I've dealt with at home and work, I may be able to help) 2) records in your realmd.realmlist table 3) the lines in your mangos.conf and realmd.conf, specifically BindIP and Port lines I was going to suggest reading the guide on setting up mangos for intranet and internet use, but it sounds like you may have done so already

Well this is starting to become a bug thread for a non-MaNGOS project, but hopefully nobody minds too much. I'm not very familiar with PHPBB but I would assume since you cannot login as an admin to change the settings you could theoretically rename the files used for the authentication process, this will require FTP access or some other way to modify files. 1) rename "auth_wow.php" to "auth_wow.php.bak" 2) copy the previous auth file you used (I don't know what the name of this file would be, sorry) and name it "auth_wow.php" 3) login as admin and change your settings back to how they should be (follow steps 4-6 in xeross155's first post, just choose your previous auth instead of WoW) If this worked you can delete the new "auth_wow.php" and you can delete or rename your old "auth_wow.php.bak" file. I would suggest waiting for a new patch to resolve your problem or write one your self Assuming you don't have a more serious error lurking around, this should revert your auth settings. But like I said I'm not familiar with PHPBB and this is all in theory only

Although I'm not part of the PHPBB Registration Bridge project, I'll point out that those errors are not caused by PHPBB RB. They are only telling that you are missing php extensions/modules. If you installed PHP from source make sure to use the --with-sqlite configuration switches, more info available at http://us2.php.net/manual/en/sqlite.installation.php, if you installed from a package system providing by your OS distribution make sure to install the php-sqlite packages as well to resolve this issue. I do not know if those extensions are required by this project or not, I'm only posting how to resolve your issue Edit: I just glanced at the source code and its using the mysqli library in php so you would need to make sure to compile with ./configure --with-mysql=/usr/bin/mysql_config --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd as an example, or install the appropriate packages for your OS distro as mentioned above http://us2.php.net/manual/en/mysqli.installation.php A note to the author, maybe add in support for selecting mysql or mysqli by the user so they can choose to use what they have installed Also pdo.so and sqlite.so should be enabled by default, which is odd that you get an error stating they are not there. What version of PHP are you using and have you customized it yourself any?

Oh yes, I forgot about PgSQL being a supported database. My concern was not for wasted disk space, but for the wasted resources that would have to deal with the excess data that wouldn't even be used. Thanks for the reply, a simple explanation was exactly what is was looking for and choosing to support both MySQL/PgSQL makes perfect sense why we would have to use datatypes that aren't the proper type for one DB, but the only type for another

I noticed today that everywhere that references date/time MaNGOS is using a unix timestamp and storing that in the DB as a bigint(11). This makes sense for 64bit systems that actually use a 64bit time_t, but on 32bit systems generally a 32bit time_t is defined in the standard C lib. So with that said, for all of us users running a 32bit OS we are wasting 4bytes for every timestamp in the DB Example: Table `character_achievement_progress` has 5925 records (in my DB ), that's 23700 bytes wasted because the timestamp is being stored as bigint, and there are many tables that store timestamps like this Would it be logical to switch the timestamps to something platform independent like using MySQLs DATETIME storagetype, I know thats still 8 bytes but at least we're not wasting any that way. This is not a database request at all, and I also know that changing from a timestamp to a different format would require extensive changes to all the source code that uses these timestamps, I'm only curious to know what others think Side Note: Yes I know all of us 32bit people are going to need to make a switch to 64bit before the Y2K38 bug rolls around