Dropped Table Recovery in SQL

Quote:

Originally Posted by .Curious. I wonder If I can have any benefit from it. CharItems exist and up to date so if CharID matches with the Charname correctly it will mean : no loss for the matching char. Accounts and chars older than 11 days will loose nothing. That sounds good but datas for 11 days old chars will also remain in CharItems. New created chars will match with the existing charIDs which do not have related CharNames in Chars. Am I wrong? Any idea about it? Any theory ?

Quote:

Originally Posted by KarmaIsMe PM me curious and I will explain your issue

Quote:

Originally Posted by castor4878 an argument is not better because it is written in bold, so the first nice idea is to stop these useless bold.

Quote:

your tables were drop because, one - hacked - stored procedure contains the drop statements or more likely because the ID/password are weak ("shaiya" ?). of course, having an human dropping these bases and then denying having done is a very standard reason.

Quote:

the Users_Master table is only used for login, it contains username and password, their values have no interest / meaning but of course each player have to know his/her pair values. you can imagine to recreate manually that table; a ticket (with former ID / password) sent by each player will be helpfull (it will avoid you to contact each of them to give a new ID/pwd). Still the UserUID fields will not be paired with some characters. the Chars table does contain these characters and each record shall be linked by an UserUID, you can also imagine to manually build that table; some of the fields will be defined by player (such as toon's name, hair, face, size, ... - you will give them rename and appearance stones), or recomputed (eg the chars stats, you will provide some stats reset stone), levels are or are not an issue, if your server is a grinding one, you have an issue, if all players have a level whatever, just set it. the PvP kills (K1-4) are lost you can not assume their old values, same for money; the last (map & position) will be set to AH. such table can be build with the CharItems information, eg if the weapon with a given CharID are all archer's weapon then that char. was an archer, and so on, for each items grouped by CharID. but of course you have no clue to know with UserUID holds these items and thus this char. if you have +/- 20 chars to handle, it can be possible to rebuild the table (also because, we know - even if not intimately - these players). if you have 100+ players just forget it, offer some free items / whatever to convince players to restart a new account and (re)create their toons. and of course communicate with the usual bullshit about the alleged strengthening of security measures.

Quote:

Originally Posted by .Curious. I will wait till night if I can not find an other option I will write a quiry to delete datas not related to existing CharIDs (Which are rollbacked from backups of 11 days ago) in CharItems so new created charIDs will not match the existing ChatItems datas. When I only reroll two missing tables from backups of 11 days ago ,old players will not loose any items gained within 11 days they will only loose kills.

delete from CharItems where CharID not in (select CharID from Chars)

-- you will also need to clean up the skills and quests per chars tables

delete from CharQuests where CharID not in (select CharID from Chars)
delete from CharSkills where CharID not in (select CharID from Chars)

use PS_GameData
GO

create table CharsSave (
	CharID int NOT NULL,
	Money int NOT NULL,
	K1 int NOT NULL,
	K2 int NOT NULL,
	K3 int NOT NULL,
	K4 int NOT NULL)

insert into CharsSave (CharID, Money, K1, K2, K3, K4)
	select CharID, Money, K1, K2, K3, K4 from Chars

update Chars
set Chars.Money=sv.Money, Chars.K1=sv.K1, Chars.K2=sv.K2, Chars.K3=sv.K3, Chars.K4=sv.K4
from CharsSave sv
where sv.CharID=Chars.CharID

drop table CharsSave