[Dokins]

pawn Код:

MySQL_GetFloat(sqlid, fieldname[], tablename[])
{
    new query[256];
    format(query, sizeof(query), "SELECT %s FROM %s WHERE id = %d LIMIT 1", fieldname, tablename, sqlid);
    mysql_query(query);
    mysql_store_result();
    new result = mysql_fetch_int();
    mysql_free_result();
    return result;
}

I tried making my own, will this work?

[AndreT]

No.

Your problem is that mysql_fetch_int() returns an integer, not a float. This means you lose floating point precision.

Another problem here is that this approach is absolutely disgusting - a function which will run a query for every value you wish to obtain? I have seen this before, but in 2008 in large roleplay gamemodes. Back when the scripters there had close to zero idea how to nicely implement database interactions because MySQL was just a small rising trend among us.

Now times are different, you have plenty of quite powerful MySQL plugins to operate with, Dan's and BlueG's just to mention two (latter is being maintained by Pain123 though). And queries like that often aren't supported anymore, and I don't see why they should be.

If you want some more ideas on how to interact with databases (and why and how to do it at once for the data that you need obtained instead of querying for it every time you need one value), see the link in my signature.

[Dokins]

Quote:

Originally Posted by AndreT No. Your problem is that mysql_fetch_int() returns an integer, not a float. This means you lose floating point precision. Another problem here is that this approach is absolutely disgusting - a function which will run a query for every value you wish to obtain? I have seen this before, but in 2008 in large roleplay gamemodes. Back when the scripters there had close to zero idea how to nicely implement database interactions because MySQL was just a small rising trend among us. Now times are different, you have plenty of quite powerful MySQL plugins to operate with, Dan's and BlueG's just to mention two (latter is being maintained by Pain123 though). And queries like that often aren't supported anymore, and I don't see why they should be. If you want some more ideas on how to interact with databases (and why and how to do it at once for the data that you need obtained instead of querying for it every time you need one value), see the link in my signature.

Thank you for the assistance, but you need to chill out.

1. I'm learning to script so by referring to a method as 'absolutely disgusting' is highly disrespectful.
2. Why make things difficult when you can make them easy?
3. I've no idea how to use those items you listed as it's not the way I learned.
4. I asked a simple question and it has no effect on who I am or what I do, therefore I don't need a lecture about trends or what you think.

[Dokins]

Quote:

Originally Posted by ****** No: 1) No input sanitation. 2) Incorrectly using thread callbacks (i.e. not). 3) Basically wasting the whole point of using a database by making it a glorified INI file. 4) Implementing said glorified INI system badly by performing each query indepedently (a la dini - the INI system universally accepted as terrible for exactly this reason). 5) I've said before and it applies here too. The MySQL plugins and the inbuilt SQLite system are not for learning SQL, they are for use by people who already know SQL and want to use that knowledge in SA:MP. If you don't know it, you actually probably better off sticking to INI.

I was taught this way of doing it. I don't know any other way and since my entire script is MySQL I have to stick to it. I've used functions similar to this throughout my script and I have had no issues, I don't see why I should change.

[Kreatyve]

MySQL isn't meant for receiving single bits of data whenever you want.

MySQL is used for loading and saving LARGE amount of data in a more organized manner.
MySQL is also great for sharing information among other programs, since a lot of programs utilize MySQL.

It is BEST to use MySQL on what I call 'start-up' callbacks (such as; OnGameModeInit, OnPlayerConnect) and/or timers that are called every more than 2minutes (Such as those that back-up server data).

[Dokins]

Quote:

Originally Posted by Kreatyve MySQL isn't meant for receiving single bits of data whenever you want. MySQL is used for loading and saving LARGE amount of data in a more organized manner. MySQL is also great for sharing information among other programs, since a lot of programs utilize MySQL. It is BEST to use MySQL on what I call 'start-up' callbacks (such as; OnGameModeInit, OnPlayerConnect) and/or timers that are called every more than 2minutes (Such as those that back-up server data).

That was a clearer answer, I appreciate that.

[AndreT]

Sorry if I came off as an asshole, I didn't really intend to.

The code you posted, while it is flawed in relative terms, could provide to be decent learning material to go onwards from. I didn't mention input sanitizing, but in case you're either unsure what you're doing or you're going to let an user (or admin) decide about which fields get selected, you surely need to escape the query first (mysql_real_escape_string in most cases).

Threaded queries - queries which are executed in another thread, and once they finish, a callback is fired in your main thread - are a good idea since some queries are slower than others. Should a large query be executed while your server has 200 players online, it could even reflect in the server sync and player pings. AKA make things laggy. A few years ago, while I was on vacation, my server was crippled by a wrong INDEX on one of my tables: the more inserts there were, the slower they got, the slower SELECTing got, etc. So this brings me to a few other concepts to try and tackle (and this can take yeaaaaaaaaars to master) such as good database design and scalability.
The scalability is something to consider. If a frequent event (once per second per player) on your server sends out 3 queries which are all in the script (main) thread and if every query takes 5 milliseconds to execute, you're going to be in trouble. 3 queries will take 15 milliseconds together, and if you have 200 players online, it means the server should be busy querying 3000 milliseconds per a second, but how is that possible? Now this is a very rough example and in all ways can be avoided, but a-little-better-than-bad planning can avoid issues like this.

An example I can bring from my own experience, once again, is a ~300 millisecond delay once a player disconnects. This sadly also went on a production server (fml). So a tip here would be: properly index your tables, take advantage of the vast amounts of RAM your server/computer has (if some data needs to be accessed, depending on its frequency, it may be smart to put it onto the heap, so an array or perhaps dynamically allocate memory using the awesome plugins released by this community) and most important: don't stop learning about stuff. Read interesting articles, tackle realtime problems with your server and its design, read books, whatevs.

Time to end this post, wasn't trying to be an asshole, cya

[Dokins]

Quote:

Originally Posted by AndreT Sorry if I came off as an asshole, I didn't really intend to. The code you posted, while it is flawed in relative terms, could provide to be decent learning material to go onwards from. I didn't mention input sanitizing, but in case you're either unsure what you're doing or you're going to let an user (or admin) decide about which fields get selected, you surely need to escape the query first (mysql_real_escape_string in most cases). Threaded queries - queries which are executed in another thread, and once they finish, a callback is fired in your main thread - are a good idea since some queries are slower than others. Should a large query be executed while your server has 200 players online, it could even reflect in the server sync and player pings. AKA make things laggy. A few years ago, while I was on vacation, my server was crippled by a wrong INDEX on one of my tables: the more inserts there were, the slower they got, the slower SELECTing got, etc. So this brings me to a few other concepts to try and tackle (and this can take yeaaaaaaaaars to master) such as good database design and scalability. The scalability is something to consider. If a frequent event (once per second per player) on your server sends out 3 queries which are all in the script (main) thread and if every query takes 5 milliseconds to execute, you're going to be in trouble. 3 queries will take 15 milliseconds together, and if you have 200 players online, it means the server should be busy querying 3000 milliseconds per a second, but how is that possible? Now this is a very rough example and in all ways can be avoided, but a-little-better-than-bad planning can avoid issues like this. An example I can bring from my own experience, once again, is a ~300 millisecond delay once a player disconnects. This sadly also went on a production server (fml). So a tip here would be: properly index your tables, take advantage of the vast amounts of RAM your server/computer has (if some data needs to be accessed, depending on its frequency, it may be smart to put it onto the heap, so an array or perhaps dynamically allocate memory using the awesome plugins released by this community) and most important: don't stop learning about stuff. Read interesting articles, tackle realtime problems with your server and its design, read books, whatevs. Time to end this post, wasn't trying to be an asshole, cya

Thank you very much for putting the time and effort in to write all of that, I'm going to read and try and understand it. Everyone has rough days and don't mean to do things, I apologise if I came off not nicely either. Thank you for understanding.