[LiamM]

Hey, guys.

So recently I have been re-scripting how my ban system works... This isn't really a problem but during the testing stages I came across quite a big gap that I'm so glad I didn't completely overlook it before bringing it out.

Right now I had a checkup when a player connected with their master account name, to see if that master account was in the banned database, if so to notify them that this account had been banned and then kicking them from the server.
What I hadn't realized was... I keep logs of the IP's of every member who is banned inside the database, but I wasn't using that row to check if they may have came back with a new master account but the same IP. Because I was only checking for the master account, they could easily slip back in with the same IP as long as the master account was different.

So my simple question is... Instead of doing this and ONLY checking for the master account

pawn Код:

public OnPlayerConnect(playerid)
{

    new query[128];
    
    format(query, sizeof(query), "SELECT * FROM `BannedPlayers` WHERE MasterAccount='%s'", PlayerName(playerid));
    mysql_function_query(dbHandle, query, true, "CheckBannedList", "i", playerid);

If it possible to use an OR function with MySQL? I'm aware that there is an AND function, but then that would check if the master account and Ip matched the same ones in the database, meaning it would let them in if one or the other was different. So I was wondering if an OR function was available to say that... If one or the other matched, kick them from the server.

So it would then be more like

pawn Код:

public OnPlayerConnect(playerid)
{

    new query[128];
    
    new plrIP[16];
    GetPlayerIp(playerid, plrIP, sizeof(plrIP));

    format(query, sizeof(query), "SELECT * FROM `BannedPlayers` WHERE MasterAccount='%s' OR IP='%s'", PlayerName(playerid), plrIP;
    mysql_function_query(dbHandle, query, true, "CheckBannedList", "i", playerid);

Then simply check to see if any rows return with a matching IP OR MasterAccount, and deal with that player accordingly.

Thank you guys. It's really hard to explain something you're un-sure about but I'm not one of the people who just EXPECT an answer. I at least give you guys my view of it to see if it would work and if it wouldn't... or even if there is a better way in doing it.

[Misiur]

That's exactly how you should do it. However use mysql_format istead of format with %e instead of %s for strings (escaping), and mysql_tquery instead of mysql_function_query, likewise:

Quote:

mysql_tquery(dbHandle, query, "CheckBannedList", "i", playerid);

http://dev.mysql.com/doc/refman/5.0/...operators.html

[LiamM]

Oh so %e escapes the string for you without the use of mysql_real_escape_string?

What is the difference between mysql_tquery and mysql_query_function?

If it's better to use I'll replace all my function queries with mysql_tquery!

[Misiur]

Yup, that's what %e does.
mysql_function_query is kept only for backwards compability (so when you update plugin the code won't break), in fact it's just a macro:

pawn Код:

#define mysql_function_query(%0,%1,%2,%3,"%4"%5) mysql_tquery(%0,%1,%3,#%4%5)

Caching is always enabled, so the "use cache" argument is not neccessary. When R36 is out, there will be a new mysql_pquery, which uses multiple cores - but that will be explained in some tutorial later.

[LiamM]

Caching is always enabled? What about if you don't need to use the cache for a query? Say an update? Would it still cache that information? or does it automatically detect what to cache and what not too? This is intriguing. I think I'll move to mysql_tquery and use the %e instead of %s for escaping strings.

I learned more than expected today, really appreciate that!

[Misiur]

mysql_tquery is using a threaded query. It means that it will execute parallelly to your script, and when it's finished, it calls your callback. Inside the plugin, it checks if you've provided a callback, and if not, it will show you a message like:

Quote:

no callback specified, skipping result saving

creating no cache for that query.

Update query result is often very important (insert ... on duplicate key update), but if you don't specify a callback, there is no unnecessary information saved.