[PaYkOK]

Hi, I was fooling around a little bit and I came across a obsticle that I cannot seem to overcome... How can I load mysql r39 data with sscanf?

I tried it like this:

pawn Код:

mysql_format(database, query, sizeof(query), "SELECT * FROM `server`");
mysql_tquery(database, query, "load", "");

and under the 'load' function

pawn Код:

if(cache_get_row_count())
{
new string [135];
sscanf(string, "p<|>e<s[20]s[5]ifis[20]s[60]>", sData[servername], sData[serverversion], sData[maxping], sData[maxpacketloss], sData[maxteams], sData[website], sData[serverpassword]);

format(string, sizeof(string), "hostname %s %s %s", sData[servername], sData[serverversion], sData[website]);
SendRconCommand(string);
.
.
.
}

Whats wrong, and could someone explain and preferably show me?

I know that I can use cache_get_field_content(_int, _float) and that its somewhat faster loading, but for the sakes of learning I wanted to do it like that...

[Vince]

Do you realize you're attempting to split an empty string? Let's say you have a basket and a bunch of unsorted fruits. You're trying to sort the fruit in the basket before even having put any fruit in the basket. Not the best analogy but I hope you get my drift.

R33+ does not require sscanf (or other string splitting) because each value is fetched individually. Fetching the whole row as one big string, if it were at all possible, would be counterproductive.

[PaYkOK]

Yeah, I just noticed that I did that... Well, at least I can use sscanf to split, lets say coordinates which are saved in one field after loading it with cache_get_field_content_*

Код:

1st field | x,y,z | 3rd field

cache_get_field_content(0, "coords", string);
sscanf(string, "p<,>fff", x, y, z);

Which, in my opinion, looks much more neat in the database than having 3 seperate fields

[Vince]

That entirely defeats the purpose of using a relational database and contradicts the first normal form. Do not ever store more than one value in a column. If you have too many columns you should ask yourself if you shouldn't separate the table into multiple new tables. I generally advice that anything that does not apply to all players to not be stored in the players table. The main player table should contain their name, email, password and all that mumbo jumbo, but not ban data or weapons or factions or cars or anything like that.