Es geht hier um das falsche setzen von Backticks.
Das macht das korrekte optionale Setzen der Ticks im Umkehrschluss aber nicht falsch. 
Dass falsch gesetzte (bzw. hier fehlende) Ticks falsch sind ist selbsterklärend.
klinke mich hier auch aus
Ebenso. Ich denke es wurde alles gesagt und jeder kann jetzt selbst entscheiden, ob er sie nutzt oder nicht.
format(query,sizeof(query),"UPDATE accounts");
format(query,sizeof(query),"%s SET level = '%d', kills = '%d', deaths = '%d',", query, PlayerInfo[playerid][pLevel], PlayerInfo[playerid][pKills], PlayerInfo[playerid][pDeaths]);
format(query,sizeof(query),"%s cash = '%d', bank = '%d', rp = '%d',", query, PlayerInfo[playerid][pCash], PlayerInfo[playerid][pBank], PlayerInfo[playerid][pRP]);
format(query,sizeof(query),"%s spawnhealth = '%d', jobID = '%d', fracID = '%d',", query, PlayerInfo[playerid][pShealth], PlayerInfo[playerid][pJob], PlayerInfo[playerid][pFrac]);
format(query,sizeof(query),"%s adminlevel = '%d', paycheck = '%d', payminutes = '%d',", query, PlayerInfo[playerid][pAdminLevel], PlayerInfo[playerid][pPaycheck], PlayerInfo[playerid][pPayminutes]);
format(query,sizeof(query),"%s leader = '%d', fRank = '%d', mute = '%d',", query, PlayerInfo[playerid][pLeader], PlayerInfo[playerid][pFRank], PlayerInfo[playerid][pMute]);
format(query,sizeof(query),"%s Kh = '%d', KhZeit = '%d', Interior = '%d',", query, PlayerInfo[playerid][pKh], PlayerInfo[playerid][pKhZeit], PlayerInfo[playerid][pInt]);
format(query,sizeof(query),"%s premium = '%d', payseconds = '%d' WHERE id = '%d';", query, PlayerInfo[playerid][pPremium], PlayerInfo[playerid][pPayseconds], PlayerInfo[playerid][p_id]);Funktioniert einwandfrei, die Ticks sind nicht falsch.
Funktioniert einwandfrei, die Ticks sind nicht falsch.
Sie sind von der Syntax her komplett falsch.
' ' für Strings bzw. Texte
` ` für Felder die auch SQL Anweisungen sein können
Das es funktioniert, macht die Sache nicht richtig.
so habe es eingebaut und es getzt aber nur beim ersten Fahrzeug beim 2 Fahrzeug steht wieder NULL
nicht vergessen habe MSQL R39-3
Tabelle umformatieren.
Standard von NULL zu eigene Eingabe ändern.
Dort dann 0 eintragen.
Sie sind von der Syntax her komplett falsch.
' ' für Strings bzw. Texte
` ` für Felder die auch SQL Anweisungen sein können
Das es funktioniert, macht die Sache nicht richtig.
Ich sage ja, solche Fehler werden meistens selber korrigiert. Aber gibt genug Lesestoff auf der Seite davor.
- desweiteren sind Anführungszeichen hier vollkommen fehl am Platz, weil es ein Float oder Double ist
Ich mache die immer automatisch und hatte nie Probleme damit. Finde das in meinem Auge übersichtlicher.
Ich glaube es macht hier keinen Sinn, das Thema weiter breitzuschlagen. Leute die sich wirklich mit der Programmierung beschäftigen, werden diese Fehler auf Dauer sowieso nicht machen.
Nur weil es keine Probleme gerade verursacht, heißt es noch lange nicht, dass es richtig ist. Es ist z.b. so, dass viele Compiler solche Fehler automatisch berichtigen, es bei anderen aber zu einer entsprechenenden Fehlermeldung kommen kann.
Das gleiche ist bei My(SQL) der Fall.
Aber BlackAce hätte es ja nicht besser sagen können. Mir ging es nur darum, solches gefährliche Halbwissen zu unterbinden.
Ich mache die immer automatisch und hatte nie Probleme damit.
Das macht ja auch im Grunde nichts, aber das die Leute sagen, sie beherrschen MySQL, ist an dieser Stelle schlichtweg nicht richtig.
Denn wenn etwas falsch ist, aber es trotzdem funktioniert, wird es dadurch nicht richtig(er).
Ich habe auf der ersten Seite Links zu Seiten verlinkt, die Dich in das Grundwissen von MySQL einweisen.
Oder so wie ich mit MySQL klargekommen bin: Datenbanken von Servern mit Script anschaffen und darin rumhantieren.
So lernt man wenigstens innerhalb eines Tages wie man mit Programmen wie Navicat, HeidiSQL oder phpmyadmin umgeht.
- Learning by doing
Gut, also nochmal:
Die Nutzung der Ticks ist nicht falsch.
Woher nehmt ihr bitte die Informationen, dass die Nutzung dafür falsch ist? Was BlackAce gesagt hat trifft meiner Meinung nach den Punkt überhaupt nicht, da er wie zuvor gesagt, sagt, dass die Nutzung falsch ist. Das ist sie nicht. Im Gegenteil.
Jony hatte ja zuvor einen Post aus einer Community verlinkt, in dem die Nutzung der Ticks als nicht empfehlenswert beschrieben wurde, allerdings nicht als falsch. Das mag des Posters Meinung sein, was ja auch völlig in Ordnung ist, aber das heißt nicht, dass niemand eine andere Meinung haben darf.
Hier ein paar Gegenbeispiele:
http://stackoverflow.com/quest…kticks-around-field-names
ZitatSo if you're using query generation features and automated re-writing of queries, backticks would make anything parsing your code less confused.
Die Nutzung der Backticks bei Spaltennamen macht eine eventuelle weitergehende automatische Verarbeitung der Queries leichter für den dazugehörigen Interpreter.
Dazu:
ZitatThe only problem with backticks is that they are not ANSI-SQL compliant, e.g. they don't work in SQL Server.
If there is a chance you would have to port your SQL to another database, use double quotes.
Heißt, wer sicher gehen will, kann anstatt den Backticks die Anführungszeichen (Doppeltick) nutzen. Wiederrum heißt das aber keineswegs, dass die Nutzung von Ticks (egal welche) falsch ist!
ZitatThere's no need, only recommendation. It is useful to represent them quoted to avoid ambiguity with SQL keywords if in future, an SQL keyword is added that shares your fields name. The only time you /need/ to quote is when a field does share a keyword name, for instance, select count from foo vs select "count" from foo will give very different results.
Wie ich auch sagte, es ist nicht notwendig. Der Poster hier gibt es selbst auch als Empfehlung aus. Hier haben wir also mehrmals das genaue Gegenteil zu dem was Jony verlinkt hat als Empfehlung.
Außerdem kann es Suchmöglichkeiten vereinfachen:
ZitatIt's a lot easier to search your code-base for something in backticks. Say you have a table named event. grep -r "event" * might return hundreds of results. grep -r "\`event\`" * will return anything probably referencing your database.
Grundsätzlich sind Empfehlungen immer vom jeweiligen Nutzer abzuwegen. Man darf nicht einfach einer Empfehlung folgen, ohne selbst nachzudenken, die Entscheidung ob man etwas macht obliegt einem immer noch selbst. Wenn mir empfohlen wird den Grand Canyon zu besuchen, ich aber Höhenangst habe, werde ich das wohl nicht machen. Ebenso werde ich den Grand Canyon aber besuchen, wenn mir jemand mit Höhenangst davon abrät, obwohl ich selbst keine Höhenangst habe.
Das Beispiel zeigt also, dass man Dinge so machen soll, wie sie für einen selbst passen.
So also hier. Man nutzt die Ticks so, wie man es für notwendig hält. Wenn man nie eine Portierung auf einen SQL Server durchführt (warum sollte man das mit SA-MP machen?!), dann spielt es absolut keine Rolle, ob man sie nutzt oder nicht - zumindest nicht dort, wo es Pflicht ist. Es kann aber nicht falsch sein!
Hierzu dann noch:
http://www.heidisql.com/forum.php?t=8781 (Letzter Post)
ZitatBack-ticks have more, maybe even more important additional values which are reason why use of them for schema identifiers is considered a good practice. But about that I can write even more..
Um jetzt die Meinungen abzuschließen, hier das Zitat von mysql.com aus der Dokumentation:
http://dev.mysql.com/doc/refman/5.7/en/identifiers.html
ZitatAn identifier may be quoted or unquoted. If an identifier contains special characters or is a reserved word, you must quote it whenever you refer to it. (Exception: A reserved word that follows a period in a qualified name must be an identifier, so it need not be quoted.)
Es steht also auch hier nirgends geschrieben, dass die Nutzung falsch ist, sondern nur, dass es nicht in jedem Fall notwendig ist.
Ich sehe daher keinen Grund warum hier das Gegenteil behauptet wird, ohne Quellen anzugeben.
Deshalb:
Wer sie nutzen will, soll sie nutzen. Wer nicht, der nicht. Meine Empfehlung, vor allem für Anfänger, ist nach wie vor die Ticks zu nutzen, um Fehler vorzubeugen. Diese Empfehlung wird auch so lange Bestand haben bis jemand einen Nachweis (keine Meinung in einem Forum!) bringt, dass die Nutzung falsch ist.
Nochmals als Fazit:
Die Nutzung der Ticks (welche Form auch immer) ist, sofern korrekt gesetzt, nicht falsch! Sie ist in manchen Fällen Pflicht, in den restlichen Fällen optional. Dies impliziert daher, dass die Nutzung an optionaler Stelle nie falsch sein kann. Sie mag nicht immer notwendig sein, aber sie ist keineswegs falsch.
___________________________________________________________
Damit zurück zum eigentlichen Thema - denn obige Diskussion hat damit rein gar nichts zu tun:
@Paddy89
Wie sieht denn dein Code momentan aus und was gibt das MySQL Plugin im MySQL Log aus, wenn du die beiden Fahrzeuge erstellst?
Kannst du das beides mal posten?
Was ich nicht verstehe, wieso ignorierst du meinen Beitrag (Link: MSQL Speichert als "Null")? Dort hab ich dir eine Alternative angeboten. So, wie du das machst, ist doch umständlich.
Deine Reihenfolge ist:
1. neuer Eintrag in deine Tabelle einfügen mit dem Name des Fahrzeugeigentümers - egal, ob es bereits so einen Eintrag gibt
2. du aktualisiert diesen Eintrag mit weiteren Werten
3. du aktualisiert erneut diesen Eintrag mit den restlichen Werten
Meine Reihenfolge ist:
1. prüfen, ob es einen Datensatz mit dem Namen des Fahrzeugeigentümers gibt
2a. ja, es gibt einen - also aktualisiert diesen Datensatz mit den aktuellen Werten
2b. nein, es gibt keinen - neuen Datensatz einfügen mit allen aktuellen Werten
Was macht nun mehr Sinn?
Außerdem hab ich dir empfohlen, für die Felder in deiner Tabelle Standardwerte zu nutzen, da du dadurch Resourcen sparst und solche Fehler vermeiden kannst.
Gib mir mal bitte den Link zu deinem MySQL Plugin, damit ich mir die Include ansehen kann (wegen den Befehlen).
Nachträglich bearbeitet:
Probier das mal
public OnPlayerBuyCar(playerid,Model,Preis,Autohaus)//CARSYS
{
if(IsPlayerConnected(playerid) && !Dtc_PlayerHaveCar[playerid][Dtc_PlayerKey[playerid]])
{
CallRemoteFunction("M_GivePlayerMoney","id",playerid,-Preis);
Gas[Model] = GetGasMax(GetVehicleModel(Model));
SetParkPlatz(playerid,Autohaus);
new name[MAX_PLAYER_NAME], str[256], x = Dtc_PlayerKey[playerid];
GetPlayerName(playerid, name, sizeof name);
mysql_format(handle, str, sizeof(str), "SELECT * FROM `carsystem` WHERE `CarOwner`='%s_%d';", name, x);
mysql_pquery(handle, str);
if (cache_get_row_count() > 0) // <-- k.A. ob das bei deinem Plugin auch so heisst, kenn dieses MySQL-Plugin nicht!
{
format(str, sizeof(str), "UPDATE `carsystem` SET `CarNitro`=0,`CarHyd`=0,`CarWheel`=0,`CarAusp`=0,`CarSideL`=0,`CarSideR`=0,`CarFB`=0,`CarRB`=0,`CarSpoiler`=0 \
,`CarRoof`=0,`CarHood`=0,`CarVents`=0,`CarLamps`=0,`CarPJ`=0,`CarC1`=0,`CarC2`=0,`Preis`=%d,`Neon`=0 \
,`Plate`=0,`Number`='GBN-0',`Gesperrt`=0,`Sperrpreis`=0,`Kralle`=0 \
,`CarModel`='%d',`CarPos_X`='%f',`CarPos_Y`='%f',`CarPos_Z`='%f',`CarPos_A`='%f',`CarOwner`='%s_%d'"
, Model, PlayerCar[playerid][x][CarPos_x], PlayerCar[playerid][x][CarPos_y], PlayerCar[playerid][x][CarPos_z], PlayerCar[playerid][x][CarRotate], name, x);
mysql_pquery(handle, str);
}
else
{
format(str, sizeof(str), "INSERT INTO `carsystem` (`CarNitro`,`CarHyd`,`CarWheel`,`CarAusp`,`CarSideL`,`CarSideR`,`CarFB`,`CarRB`,`CarSpoiler` \
,`CarRoof`,`CarHood`,`CarVents`,`CarLamps`,`CarPJ`,`CarC1`,`CarC2`,`Preis`=%d,`Neon` \
,`Plate`,`Number`='GBN-0',`Gesperrt`,`Sperrpreis`,`Kralle` \
,`CarModel`,`CarPos_X`,`CarPos_Y`,`CarPos_Z`,`CarPos_A`,`CarOwner`) \
VALUES (0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,%d,0,0,'GBN-0',0,0,0,%d,%f,%f,%f,%f,'%s_%d');"
, Model, PlayerCar[playerid][x][CarPos_x], PlayerCar[playerid][x][CarPos_y], PlayerCar[playerid][x][CarPos_z], PlayerCar[playerid][x][CarRotate], name, x);
mysql_pquery(handle, str);
}
OnPlayerCarLogin(playerid);
printf("OnPlayerBuyCar (%s_%d)",name,x);
mysql_log(LOG_ALL);
}
}Sorry, hab meinen Beitrag eins vor dir bearbeitet, da ich das schon gefunden hatte.