Database Errors...

[crosenblum]

I have been getting 2 types of database errors...

1. The Main Server Crashes, saying it was closed by the db server, and the last few entries into the db server, are into the items table.

2. When we had guild's enabled, it would show in red CGUILD error, and it would crash the server... we had to disable guild's to prevent this error.

Now after our testing stages, i had reset the data, and truncated tables, and also dbcc reseeded them..

I wonder if anything i did was wrong..in the reset process...

Any ideas or suggestions?

Also a player was pimping their weapon...

also the other day, someone was selling a bunch of items to the npc merchant, and it crashed as well..

any thoughts or suggestions?

Here are 2 screenshots:

 

[samsam]

Re: [Q] Database Errors...

You use root server?

 

[crosenblum]

Re: [Q] Database Errors...

no, why?

Why would that have anything to do with this database bug?

 

[samsam]

Re: [Q] Database Errors...

Sorry i cant help u much but all i can tell you reinstall ur SQL or remake Database and make sure u restore kal_db and kal_auth well

 

[Flohle]

Re: [Q] Database Errors...

hint: I had the same error as on the first pic some restarts and serve stoped by loading [ETC] now I figured out that the database is damaged so had to make a new one because I don't found the mistake yet

 

[crosenblum]

Re: [Q] Database Errors...

i am not gonna do a full reinstall, that's a major effort, and i can do it, just i'd rather just fix this specific bug.

So any one have any details or clues?

 

[CloseUp]

Re: [Q] Database Errors...

look at the errors.
try to delete your odbc connections and make them again.
if that dosnt work then delete the log table and make a new log table.

USE [kal_db]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Log](
 [Date] [datetime] NOT NULL,
 [MainType] [tinyint] NOT NULL,
 [Type] [tinyint] NOT NULL,
 [Player1] [int] NOT NULL,
 [Player2] [int] NOT NULL,
 [IID] [int] NOT NULL,
 [Value1] [int] NOT NULL,
 [Value2] [int] NOT NULL,
 [Value3] [int] NOT NULL,
 [Value4] [int] NOT NULL
) ON [PRIMARY]

 

[crosenblum]

Re: [Q] Database Errors...

The server is currently up and working, but i do get those errors...

Why re-create the log table?

 

[DeathArt]

Re: [Q] Database Errors...

I can't tell what's wrong, but what I can tell is all suggestions so far in this thread is completely derailed and retarded.

Seriously, people should shut the fuck up if they don't have a clue. Lol at blaming the log table just because it happend to be the one in the error message.

It's either one of these issues:

- Network issue (Firewall comes in mind) due to the communication link issues

- Capacity issues (got enough HD space?)

The KalServer software's way of reporting errors is useless, so you want to go check the systemlog to see if MSSQL reported any errors itself. Should be np for a person like you who claimed to have worked with it for years, lulz.

 

[crosenblum]

Re: [Q] Database Errors...

I have 2, 500 gig hard drive's, the main one still has tons of space left.

I am using a router, that has it's own firewall/port forwarding etc...

Most of my db work has been in rewriting queries, designing tables etc, not so much admin, error fixing etc...

But i do appreciate your suggestions...

 

[_Varis_]

Re: [Q] Database Errors...

Skip down to the bold if you don't want to read my rant...

My suggestion has been and still is just to not meddle in the database. Other servers whose admins don't do as much meddling (or any meddling at all) have 99.9% less crashes.

So you've messed about in the database, you now have errors. Big surprise there.

If you can't tell us what you did, and you don't want to go to the effort of doing a DB restore, what can we do to help you?

No one can reproduce the bug, because we (for some reason) deemed it a bad idea to go mucking about in a database that was built four years ago half a world away. People have succeeded in messing with the DB without problems, but they did a whole lot more looking into what they were editing before they dove in and added columns for their shiny PHP scripts to use.

Just my two cents in the form of a rant.

Now for a meaningful suggestion- you don't have to store all your Drupal crap in kal_auth and kal_db... perhaps you should consider storing that in another table, and letting your PHP reference both places (you can instruct it to look at more than one table, it's not stupid, you know). That's what the relational database was made for, you know. Besides, unless you've totally taken apart the DB server (which I know for a fact you haven't), you really can't know what you could possibly mess up by adding a bunch of extra junk to your entities.

-V

 

[crosenblum]

Re: [Q] Database Errors...

Now as for my database, i have two seperate ones, mysql and sql server 2005. mysql has all the website related information, and sql server all the kal related information...

So how can a mysql database possibly affect a sql server one???

And i haven't been messing in the database, other than to do the reset after our beta/test stage...

1 field in the Login table, of kal_auth, that can't isn't a lot of crap? All i am storing is the site account id, for easier lookups.

So i have no idea where your getting this strange idea that i've done lots of things to the database, when i haven't.

 

[_Varis_]

Re: [Q] Database Errors...

MSSQL does not simply break itself out of the blue. It needs help to do that.

I remember at least three instances off the top of my head where I needed to get on your PC on remote desktop because your server was crashing and pull a change out of your database that you insisted could not possibly affect Kal.

Presto, the server worked again after each time.

Here's a parable for you: A man backs into a telephone pole on three separate occasions. Each time it happens he brings his car to the same mechanic to fix. One day, he comes in a fourth time to the mechanic with a mangled bumper. What does the mechanic think happened?

-V

 

[General]

Re: [Q] Database Errors...

@Varis: Strange, all of my php scripts work perfectly with new tables in both databases...

But a simple rule; never modify existing tables, always make new ones... Dont save SN's in Login but in Login_Extended.

Becuase, some queries in kal only use VALUES to start with e.g. "INSERT INTO Login VALUES (xxx)", so the amount of columns must match the amount of inserted columns. Adding or changing a column would mean big trouble in this case.

Best thing to do now is reinstall the original DB and keep your hands of the existing columns/

 

[_Varis_]

Re: [Q] Database Errors...

@Varis: Strange, all of my php scripts work perfectly with new tables in both databases...

Yeah I don't think his PHP scripts broke it, I think the columns he added (for the PHP scripts to use) broke it. He didn't add tables, he meddled with current ones and did exactly what you said; he added columns to current tables, disregarding the queries stored in DbSvr.

@crosenblum: Think of is this way. If there is an array of set length in MainSvr or DbSvr for a row to be read into (or there is a query like Bjorn mentioned), and there are more (or less) fields than the array is prepared for. What do you think would happen?

-V