ObjectId, OwnerId, Location, data, data2, data3, data4

The objectId would be the key for the table prevent duplicate entries natively by design - the ObjectID would be a thread safe IDFactory (server wide) and can be used for many things, but specifically, AccountID, CharacterID, MailID, etc.

Then you'd have your tables for Accounts, Characters, Mail, etc ... which with the reference to the Unique ID and loaded at server run time into memory - and written to the table as needed (items would Save instantly, always... as an example... but characters/exp gains could save on an timer thread such as every 5 minutes to reduce I/O Load).

When working with the "Inventory Table":

ObjectId, OwnerId, Location, data, data2, data3, data4

All instantiated items would exist in this table where the OwnerID would be where the item resides:

OwnerID = CharacterID for character Inventory
OwnerID = MailID for character mail - the Mail Table would reference its Character ID as to who owns it.
OwnerID = AccountID for Account Based storage... this would allow you create account based storage for moving items between characters on an account - shared storage..
OwnerID = GuideID for Guide Based storage...
OwnerID = MonsterID for pets... this would allow you to store pets with items on them still (solves that problem for you).

The benefit of this system, is that instead of DELETE and INSERTS you are doing simple UPDATES - so now you can't force a dupe through any type of race condition or logic error... because the object will only ever exist ONCE and get its reference in the database updated when traded / dropped / stored

At this point, the only thing you'd have to worry about is stackables - because the objectID would need to be recreated when splitting stacks - making them potentially still dupable.. but there are ways to track this and prevent it as well.

The location property would be a reference for loading and accessibility...

0 = Ground
1 = Inventory
2 = Account
4 = Mail
8 = Guild
16 = Pet
.... etc

Race Conditions, Signed type overflows, client data validation as some examples with my favorite tactic to create a proxy that the client connects to... which connects to the server and handles all the fun stuff. I will play around when the new server comes out...

I had an explanation referencing all the cool old memories like back in the day when you added in the logoff delay when you were in combat.. and we would dupe all the stat elixirs by killing the player JUST as they logged off so the items would drop, but the server never removed it from the players inventory... oh the good memories.

Angeldust,

You ok if I were to do some exploit testing on the new server code? (are we running the new server or old + new client?). The goal would be testing to report/fix.