[MySQL] Insert query met int plaats andere waarde in tabel

[Bbfreak]

Ik heb de volgende tabel aangemaakt;

SQL:

CREATE TABLE IF NOT EXISTS `users` (
  `facebook_id` int(50) NOT NULL,
  `name` text NOT NULL,
  `emailaddress` text NOT NULL,
  `first_visit` datetime NOT NULL,
  `last_visit` datetime NOT NULL,
  `status` text NOT NULL,
  PRIMARY KEY (`facebook_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Als ik nu de volgende query uitvoer:

SQL:

INSERT INTO users(facebook_id,name,emailaddress,first_visit,last_visit,status) VALUES ('100002126139276','Jenine Hoff','','2012-09-13 21:52:11','2012-09-13 21:52:11','NOT REGISTERED')

Krijg ik vreemde resultaten. Hij voert nl niet 100002126139276 als facebook_id in maar een ander random getal.
Doordat hij dit doet probeert hij bij het volgende bezoek van de persoon opnieuw een insert omdat een select met het facebook_id geen resultaat oplevert.
Dit gebeurd bij meerdere mensen maar ook bij heel veel niet.

Wie heeft er enig idee?

[Hydra]

Haal die quotes rond die integer eens weg?

Edit: Je had de correcte tag al gevonden

[ Voor 74% gewijzigd door Hydra op 19-09-2012 10:54 ]

[alienfruit]

Uhm. Moet je niet een BIGINT gebruiken voor een facebook id

[Bbfreak]

alienfruit schreef op woensdag 19 september 2012 @ 10:54:
Uhm. Moet je niet een BIGINT gebruiken voor een facebook id

Hmm daar lijkt het wel op my bad...het werkt.

[_Erikje_]

fyi, het 'random getal' was waarschijnlijk het effect van een integer overflow

[NMe]

Zo random is het getal 2,1 miljard niet. Eigenlijk zou iedere programmeur dat moeten herkennen, al heb ik zelf ooit een keer exact dezelfde fout gemaakt.

[RobIII]

[q="http://dev.mysql.com/doc/refman/5.0/en/out-of-range-and-overflow.html"]
11.1.4.6. Out-of-Range and Overflow Handling
When MySQL stores a value in a numeric column that is outside the permissible range of the column data type, the result depends on the SQL mode in effect at the time:

• If strict SQL mode is enabled, MySQL rejects the out-of-range value with an error, and the insert fails, in accordance with the SQL standard.

• If no restrictive modes are enabled, MySQL clips the value to the appropriate endpoint of the range and stores the resulting value instead.
[...]

Ofwel: strict mode aanzette; en niet alleen voor overflows

[mro95]

Bbfreak schreef op woensdag 19 september 2012 @ 10:51:
Ik heb de volgende tabel aangemaakt;

SQL:

CREATE TABLE IF NOT EXISTS `users` (
  `facebook_id` int(50) NOT NULL,
  `name` text NOT NULL,
  `emailaddress` text NOT NULL,
  `first_visit` datetime NOT NULL,
  `last_visit` datetime NOT NULL,
  `status` text NOT NULL,
  PRIMARY KEY (`facebook_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Als ik nu de volgende query uitvoer:

SQL:

INSERT INTO users(facebook_id,name,emailaddress,first_visit,last_visit,status) VALUES ('100002126139276','Jenine Hoff','','2012-09-13 21:52:11','2012-09-13 21:52:11','NOT REGISTERED')

Krijg ik vreemde resultaten. Hij voert nl niet 100002126139276 als facebook_id in maar een ander random getal.
Doordat hij dit doet probeert hij bij het volgende bezoek van de persoon opnieuw een insert omdat een select met het facebook_id geen resultaat oplevert.
Dit gebeurd bij meerdere mensen maar ook bij heel veel niet.

Wie heeft er enig idee?

facebook_id is je primairy key, als ik zou was zou ik gewoon een tabel user_id maken en dat gebruiken als primairy key, dus zo:

SQL:

CREATE TABLE IF NOT EXISTS `users` (
  `user_id` int(11) NOT NULL, 
  `facebook_id` int(50) NOT NULL,
  `name` text NOT NULL,
  `emailaddress` text NOT NULL,
  `first_visit` datetime NOT NULL,
  `last_visit` datetime NOT NULL,
  `status` text NOT NULL,
  PRIMARY KEY (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Ik hoop dat dit je helpt

[ReenL]

mro95 schreef op woensdag 19 september 2012 @ 19:55:
[...]


facebook_id is je primairy key, als ik zou was zou ik gewoon een tabel user_id maken en dat gebruiken als primairy key, dus zo:

SQL:

...

Ik hoop dat dit je helpt

offtopic:
Dat helpt niet omdat facebook_id in een BIGINT moet, en is ook nog eens traag omdat facebook_id nu geen index heeft.

Het getal in MySQL achter int (in dit geval de 50) heeft iets met padding te maken, maar niet met de grootte van het getal wat je erin kan proppen.

Je kan het veld ook unsigned (+BIGINT) maken aangezien facebook geen negatieve id's kent.