View Single Post
  #8  
Old 07-24-2011, 09:54 AM
ffcmike ffcmike is offline
Banned
Join Date: Jul 2004
Location: London
Posts: 2,029
ffcmike has a reputation beyond reputeffcmike has a reputation beyond reputeffcmike has a reputation beyond reputeffcmike has a reputation beyond reputeffcmike has a reputation beyond reputeffcmike has a reputation beyond reputeffcmike has a reputation beyond reputeffcmike has a reputation beyond repute
Send a message via AIM to ffcmike Send a message via MSN to ffcmike
Quote:
Originally Posted by xXziroXx View Post
Maybe you have communityname set to UNIQUE? Would explain why the person with "guest" as community name didn't work.
If this was the case this would be occurring for every single guest that logs onto the server, but it is only a small minority.

Quote:
Originally Posted by Mark Sir Link View Post
the issue with the first one seems to be num being 0, I imagine that is already being used in an entry
The unique index is on both num and pid joined together, as in to prevent the same player from having a task entry added twice.
It's definitely not the issue with this, it can just as easily happen with values above 0.

Quote:
Originally Posted by cbk1994 View Post
I'm not sure this will fix your problem, but I'd recommend just doing this instead of using a flag:

PHP Code:
INSERT OR REPLACE INTO tPlayer (accountsubscriptionlastlogingelatscommunitynameVALUES ('pc:5306287''trial'13112990720'guest'
If inserting the row would cause a constraint conflict, it deletes the existing row causing the conflict and inserts the row. If there is no conflict, it just inserts the row.

It should get rid of any issues resulting from out-of-sync database/player attributes (e.g. if a player is reset or rolled back).

Note that this will change the rowid for the player's entry, but you should never rely on the rowid. If you specify a PRIMARY KEY column, it probably won't change the rowid.
I guess that would fix that half of the issue, though that would have the slight inconvenience that you can't see each player in the order they were created when exploring the data.

What I believe might be the problem is that I have the query executed after a trigger, and so by the time onPlayerStored occurs observer mode is already preventing the ability to write flags to the player.
The reason I have it like this is so not to delay any subsequent processes in the Control-NPC's login event where this SQL function is invoked from.
As in:
Control-NPC - SQL.playerLoggedIn();
Control-NPC - Someothersystem.playerLoggedIn();
SQL.onSQLCommit();

As for the issue of players somehow not being stored in the database though I have no idea, no errors are occurring at the time of logging on, I'm only noticing these accounts aren't there due to later tasks failing to add.
Reply With Quote