Mysql max allowed packet in 3.23.57, met adodb

[Verwijderd]

Hai,

Ik heb op dit moment het volgende probleem :
de max_allowed_packet van 3.23.57 kan ik niet hoger krijgen als 16M
Als ik dit bv in mijn /etc/my.cnf zet als 5M, pakt hij het wel, maar hoger als 16M maakt hij er gewoon 16M van.

Nu moet ik dus een longblob van 16.5 ( ) mb updaten, en uiteraard werkt dit dan niet, omdat de query size te groot is.

Updaten naar 4.x zit er niet in, ivm compatibiliteitsproblemen.

Nu dacht ik zelf, laat ik die blob van 16.5M opsplitsen in delen van 1M, en dan dmv een loopje een query als

MySQL:

Update mytable set file=CONCAT('blablablobdatalalala',file) where id=3

Nu blijkt hij dit echter op 1 of andere vage manier niet te pakken.

Als ik de debugger van Ado erover gooi, geeft hij een output als deze :

code:

(¢€Ŝ( ¢Ŝ(\0¢Ŝ(\0¢Ŝ(\0¢Ŝ(\0¢Ŝ(\0¢Ŝ(\0¢Ŝ(\0¢Ŝ(\€ (¢€ (¢€ (¢€
<1M aan andere vage info>
¢€ (¢€ ',file) where id=1

Zoals je ziet staat hier heel het 1e deel van de query ("update mytable") niet bij...
Maar hij geeft ook helemaal geen error / warning.

Als ik echter ga kijken bevat deze column gewoon een NULL.

Iemand enig idee hoe ik dit probleem aan kan pakken ? Ik ben er al een tijdje mee bezig, Heb de mysql geupdate naar de laatste 3.x versie.

Wat kan ik nog meer proberen ?

[Verwijderd]

Ik ben nu paar dagen verder...
Helaas nog geen reacties

Ben nu toch maar bezig met mysql op een andere server te instaleren om te testen of het daar wel op werkt. Alleen querys van 16M invoeren gaat meestal niet zo makkelijk...

Is er echt niemand die hier ooit last van gehad heeft ??

[KompjoeFriek]

Als je even op de site van MySQL zoekt, dan VIND je vanzelf iets...
maar wat voor compatibiliteitsproblemen heb je met versie 4?

[off-topic]
'kheb je topic gevonden naar aanleiding van Verplaatsing topic NOS > PWS P&W

[ Voor 7% gewijzigd door KompjoeFriek op 04-08-2003 15:03 ]

[Verwijderd]

Op site van mysql lees ik idd dat er een limiet van 16M is.
Helaas kan ik dit dus ook niet omzeilen door wat in de source te klussen denk ik, omdat ze zeggen dat het limitatie van het protocol is.

Server waarom het draait is niet van mij, en mij is verteld dat er niet geupdate word ivm compatibility problemen, wat daar verder precies de redenen van zijn weet ik zelf niet... Maar ik kan dit wel navragen.

Bedankt iig voor je commentaar

[off]
PWS / P&W, als die moeilijke afkortingen allemaal

[KompjoeFriek]

Ok, das een hele goede reden waarom je niet kunt upgraden

Maar zoals op de site staat, zit er toch echt een limiet op van 16M (helaas)
ik denk dat we je hier mee niet kunnen helpen, omdat als er ook maar een oplossing voor is, je er waarschijnlijk de root-rechten nodig hebt op je server.
(ik lees dat je MySQL wel naar de laatste versie hebt ge-upgrade, heb je soms root-rechten?)

Is die BLOB altijd 16,5M die je erin wilt hebben? of kan de grootte variëren?

want ik kan zo maar 1 oplossingen bedenken waar je misschien iets aan hebt.

Oplossinkje:
je splitst de blob, en laat die appart verstuurd worden naar MySQL, zodat je geen last hebt van het 16M limiet.
en dan naar een soort tabel structuur zoals dit:

code:

|id|part|    data    |
|--|----|------------|
| 0|   0|0123456789AB|
|--|----|------------|
| 0|   1|CDEF01234567|
|--|----|------------|

Dit heb ik net ff bedacht, en in theorie zou het wel moeten werken denk ik, maar waarom lukte je eerdere poging van het splitsen niet?
mislukte het invoeren van de blob, of ging het splitsen van de blob zelf fout?

zorg eens dat je de exacte queries zoals ze uitgevoerd worden op het scherm krijgt (en post ze hier als dat nodig is) misschien zie je dan wat er fout gaat

[Verwijderd]

(ik lees dat je MySQL wel naar de laatste versie hebt ge-upgrade, heb je soms root-rechten?)

Ik heb het lokaal even getest of hij dan wel boven de 16M lijn komt.

De blob is variabel. Dit kunnen bestanden van 1K zijn, maar ook bestanden van 200M

De eerdere poging van mij probeerde via concat de data in 1 row te proppen, maar dat ging dus blijkbaar niet. Jouw voorbeeld heeft inderdaad ook wel wat, ik weet alleen niet of ik hier nog tijd voor heb om het zo te verbouwen. Op dit moment heb ik alle bestanden fysiek op de harddisk gezet, met bestandsnaam verwijzingen in de database. Beetje ranzig is dat helaas wel.

zorg eens dat je de exacte queries zoals ze uitgevoerd worden op het scherm krijgt (en post ze hier als dat nodig is) misschien zie je dan wat er fout gaat

Die queries zijn nogal groot om in zijn geheel te tonen, met het splitten kwam het neer op paar kb per query, maar dat is dus van die onleesbare tekens zoals in mijn 1e post. Hier heb ik het dus deels afgekapt.

[KompjoeFriek]

Wat is er ranzig aan verwijzingen naar fysieke bestanden in de database?

Als dat toch werkt, waarom moeilijk doen?

_{(stom dat ik daar zelf niet eerder opgekomen ben )}

[ACM]

Probeer dit es dan?
http://www.mysql.com/doc/en/LOAD_DATA.html

Ben bang dat ook dat niet werkt, maar je kan het allicht proberen via een file te regelen.

[Wilke]

En misschien ben ik dan weer raar, maar als ik mensen objecten van 16.5 MB in een MySQL database zie stoppen, dan vraag ik me toch wel een beetje af 'waar zijn wij nou helemaal mee bezig'.

Is er geen betere manier om die BLOB op te slaan, bijvoorbeeld in een file ofzo?

Het kan best zijn dat via een database handiger is ofzo, maar toch vraag ik me af waarom...

[moto-moi]

Op verzoek naar Software Algemeen verplaatst.

[Verwijderd]

Het downloaden van blobvelden van 25mb via mysql op windows:

[mysql]
vanaf mysql 4.0.1 wordt een max_packet_size van 1gb ondersteund, daarvoor maar 16MB.
de net_buffer_lenth ook iets omhoog zetten (16mb ofzo)

[iis6 (metabase.xml)]
maxrequestentityallowed naar 25mb
(indien je asp gebruikt:) aspmaxrequestentityallowed : 25mb
MinFileBytesPerSec = 0 (belangrijk !)

in je script
buffering uit zetten
géén loop in je recordset om packets op te halen en samen te voegen, gewoon één keer de hele grootte binnenhalen.