Ik beeld jpg's af door ze uit een mysql-database te plukken, en ze met een header ("Content-type:$Type") af te beelden.
Dit lukt goed zolang de afbeelding niet groter is dan ongeveer 50KB.
Afbeeldingen die groter zijn, worden ofwel maar half afgebeeld, ofwel helemaal niet.
Iemand enig idee waar dit aan ligt?
Hier volgt de PHP-code waarmee ik de jpg afbeeld:
Wat voor type is de kolom waar je de afbeelding in opslaat?
[size=xsmall]Toevoeging op 26/11/2012 20:46:10:[/size]
Is het trouwens niet handiger om de afbeelding gewoon op te slaan als bestand en het pad en de bestandsnaam in de database? Naast dat het waarschijnlijk handiger is, is het sowieso beter voor je database omdat deze al vrij vlot in omvang zal groeien en een stuk zwaarder belast wordt bij het opvragen van een afbeelding.
Op de breedte van de kolom staat geen limiet.
De jpg rechtstreeks in de tabel steken levert geen probleem :<img align="center" src="./weg_files/boer164.jpg">
beeldt de jpg wél goed af.
Ik begin niet de 100.000.001-ste discussie over wel of niet de jpg in een database steken...
@Frits: ach, de meningen zijn verdeeld. Als database-man zeg ik: "waarom zou een filesystem beter zijn dan een database? Stop alles in je database, dan kun je veel meer met je data doen".
@Sam: Kijk eens naar je database parameter "max_allowed_packet". Het kan zijn dat het resultaat van je query ineens afgekapt wordt als packets te groot worden. Je kunt dan "max_allowed_packet" hoger instellen.
Op de breedte van de kolom staat geen limiet.
De jpg rechtstreeks in de tabel steken levert geen probleem :<img align="center" src="./weg_files/boer164.jpg">
beeldt de jpg wél goed af.
Ik begin niet de 100.000.001-ste discussie over wel of niet de jpg in een database steken...
Ik wilde ook geen discussie opstarten, maar gaf een tip over iets waar je misschien niet eens over nagedacht had.....
Ik kom toch nog een keer terug op het type van de kolom. Ondanks dat je geen breedte hebt ingesteld heeft elk type wel een maximum grootte. Een BLOB komt bijvoorbeeld niet verder dan 64KB
Geen error is niet ongewoon, sommige database engines slaan op wat ze kunnen en vergeten de rest. Niet altijd krijg je een melding TOO LONG FOR COLUMN. Welke type gebruik je?
TINYBLOB - 255 bytes
BLOB - 65535 bytes
MEDIUMBLOB - 16,777,215 bytes (2^24 - 1)
LONGBLOB - 4G bytes (2^32 – 1)
De "max_allowed_packet" zoals Ivo al zei is ook belangrijk.
@Frits: Sorry als ik grof over kwam: was NIET de bedoeling.
over Blobs in Mysql vind ik : The internal representation of a table has a maximum row size of 65,535 bytes, even if the storage engine is capable of supporting larger rows. This figure excludes BLOB or TEXT columns, which contribute only 9 to 12 bytes toward this size.
Niets over de max grootte van BLOB-fields.
Maar de grens van 64KB lijkt mij verdacht overeen te komen met hetgeen ik vaststel...
Ergens een parameter in Mysql?
[size=xsmall]Toevoeging op 26/11/2012 21:32:45:[/size]
@john D: type veranderd in Longblob lijkt de oplossing te zijn. Blob beperkt tot 64KB. wist ik niet (shame on me)
BLOB: L < 2^16 (L = the actual length in bytes of a given string value)
Ik weet niet hoe ver ed database al gevuld is of dat je nog aan het testen bent, anders zou ik het type verandern naar LONGBLOB en nog eens proberen. Dan weet je het zeker.
[size=xsmall]Toevoeging op 26/11/2012 21:34:05:[/size]
