[Helix]

Har upptäckt att vid vissa, löpa script får jag problem vid insättning av rader till databasen.

När?

Oftast när fältet är satt till att inte acceptera NULL dvs. Nej , men insättningsfrågan försöker sätt ain en blankt värde där, dvs. ''

Ok, det verka rinte konstigt och det är ju rätt hur MySQl hanterar det. Dock innan i MySQL 4 var detta inag problem. Man satta in värdet ändå. Det var inte så strikt tror jag. Märker nu att vissa script har detta problem då man inte tagit hänsyn. Läste även någonstans att MySQl 5 är mer strikt på dessa inställningar och det har jag märkt.

Lösning?

Tycker ibland jag håller på och debugga script och hittar just att databasfältens NULL värde är satt fel. Trött på det.

Finns det sätt att släppa MySQLs strikta sätt att se på det?


(Hoppas jag gjorde mig förståelig ...)

[Helix]

Hmmm ... verkar som jag besvarat den själv. Handlar kanske inte alltid om fel insätntingar.

http://blog.guidol.nl/archives/23-My...plication.html

Att sätta SQL mode till '' fungerar bättre .... eller i alla fall ta bort STRICT_TRANS_TABLES

[kullervo]

Den långsiktiga lösningen är att inte använda MySQL för data du bryr dig om.

[Clarence]

Ursprungligen postat av kullervo

Den långsiktiga lösningen är att inte använda MySQL för data du bryr dig om.

Brist på felhantering i klientkoden och/eller felaktig konfiguration är inte en bra anledning att byta system? Det finns en extrem mängd företag som använder MySQL för mycket känslig data, inklusive banktransaktioner, sedan länge utan problem. Dock är de givetvis noga med att både ha bra felhantering och välja en ACID-kompatibel tabelltyp.

Och hans problem var ju dessutom redan löst?

[Softilog]

Bland annat Oracle hanterar ju tomma strängar på samma sätt ('' = null).

[studiox]

Ursprungligen postat av kullervo

Den långsiktiga lösningen är att inte använda MySQL för data du bryr dig om.

Vilken databas ska man ha data som man bryr sig om I då? Vaknat på fel sida?