Bug #290: EOSERV does not check if bans database table exists on startup
| ID | #290 |
|---|---|
| Submitter | Hacker_Alex |
| Product | EOSERV |
| Severity | Normal |
| Status | CLOSED, FIXED |
| Submitted | 12th Feb 2014 |
| Updated | 1st Jul 2016 |
| Rev# | Date | Description |
|---|---|---|
| r535 | 01 Jul 2016 21:01:23 UTC | Ban table info is shown on startup (bug #290), NPC drops are validated (bug #359), "$d here" ... |
10 years, 42 weeks ago
Line 338 in main.cpp should read:
Database_Result ban_count = server.world->db.Query("SELECT COUNT(1) AS `count` FROM `bans`");
This will ensure that the ban table in the database is checked for on startup to prevent crashes from the ban table not existing or a ban not being saved when this table does not exist.
This way the database can be fully corrected before the server is started.
Comments
10 years, 42 weeks ago
The best bet would not to directly edit the database in the first place...
10 years, 41 weeks ago
what? I didn't say anything about editing the database directly..
10 years, 41 weeks ago
How would it get deleted then? :|
10 years, 41 weeks ago
I don't know how it would get deleted. Perhaps it was not initially built. This just removes the possibility of a user using eoserv without a ban table. (Full database) If accounts, characters, are checked for, why not bans too. Yes, they are checked for the display of how many characters/accounts were loaded but it is also for the purpose of catching errors where a table doesn't exist. Better to get the job done fully than partly.
I just feel that maybe Sausage added bans after he added accounts and characters and that display and perhaps overlooked adding a check for ban table.
10 years, 41 weeks ago
I believe the logic behind this may be the server cannot function as designed without the accounts and characters tables to begin with. To use EOSERV you should either have enough knowledge to install MySql and run the install.sql file to create the tables within the database, or rely on EOSERV to generate the Sqlite flat file (totally not recommended for servers intended for a large playerbase). I can almost support your argument that the program should greenlight the fact all needed tables should exist, but I also must frown on the possibility that someone is running a server and somehow either fails to install or deletes the necessary tables. Maybe it is a good idea to make EOSERV idiot-proof.
10 years, 41 weeks ago
I'd point out that if install.sql were run (and not edited), there is only the possibility of none or all the tables being created, so it would have to be deleted after the fact to go missing.
Also as far as I know, running install.sql will fail if it's already been run once.
It would be nice to show the number of bans on startup with all the other info though, and have install.sql not fail when it tries to re-create it. ;p
I'll create a separate bug to deal with self-repairing / updating the database.
Updated Status to CONFIRMED
8 years, 21 weeks ago
Fixed in r535.
Updated Status to CLOSED, FIXED
Add Comment
Please don't post unless you have something relevant to the bug to say.
Do not comment to say "thanks" or "fix this please".
Please log in to add comments. EOSERV Bug Tracker > Bug #290: EOSERV does not check if bans database table exists on startup