:strip_icc():strip_exif()/u/16890/crop63d37bc5be4d0.jpg?f=community)
Een kleine omschrijving van de situatie:
Ons bedrijf maakt producten in flesjes, en deze flesjes krijgen een label. Omdat we in veel verschillende landen leveren, en veel verschillende producten maken, én in een aantal maatsoorten leveren, zijn er dus nogal wat combinaties mogelijk. Om deze combinaties overzichtelijk te maken waren er oorspronkelijk per product excelsheets, en is er later een access database aangelegd met daarin de teksten voor de labels. Ieder product is een tabel, met per rij een taal, en per kolom een zin. Degene die de database beheerd doet dit rechtstreeks in de tabellen.
Bijvoorbeeld:
Op rij 4 staat bijvoorbeeld de taal FR, en er zijn onder andere de kolommen SAMENSTELLING R1, SAMENSTELLING R2 enzovoort.
Vervolgens zijn er in onze labelsoftware (Nicelabel) per maatsoort labels gebouwd (bijvoorbeeld 1 LITER, 500 ML, etc), met daarin de opmaak, en per veld is een script die RTF tekst opbouwt en via SQL statements de benodigde velden uit de access database haalt.
Het probleem:
We lopen nu tegen het volgende probleem aan. De access database is samengesteld uit de voorgenoemde excelsheets. Deze zijn stuk voor stuk geimporteerd, iedere sheet werd een tabel. Dit leek allemaal ideaal, en werkte zeer snel. Na verloop van tijd kwam degene die teksten beheerde er achter dat sommige velden niet "compleet" waren, de tekst werd afgebroken. Op het label waren de teksten echter wel compleet, dus heel urgent was het niet. Nu blijkt dat voor sommige van deze velden op voor ons onverklaarbare wijze de tekst op de labels óók afgebroken wordt, en er dus max. 255 tekens uit de database gehaald worden. Uiteraard ben ik zelf op zoek geweest naar de oorzaak, en die is deels te vinden in het importeren van excel naar access, er blijkt dan truncation plaats te vinden, ook al staat het doelveld op longtext. Dit verklaard echter niet dat de tekst wél goed op het label kwam, en het veld dus "onderwater" wel degelijk meer dan 255 tekens bevatte...
Mijn vraag:
Hoe kan het dat velden, blijkbaar spontaan, ineens maar max. 255 tekens bevatten, terwijl dit hiervoor aantoonbaar niet zo was? Daarnaast, hoe kan ik dit in de toekomst voorkomen? Zoeken wijst uit dat bij de eigenschappen van een longtext veld schakelen van "tekst zonder opmaak" naar "tekst met opmaak" meer dan 255 tekens mogelijk maakt, maar ik heb dit nog niet in de productiedatabase geprobeerd, omdat ik niet weet hoe mijn labelsoftware hier mee om zou gaan, ik ga dit van de week proberen.
Update:
Kennelijk heeft het schrijven van deze post mijn gedachten weer enigszins op een rijtje gezet, want ik heb mogelijk de oorzaak gevonden. In de veldeigenschappen van een longtext (memo) kun je de notatie (format) bepalen. De stond voor alle geimporteerde velden op "@". Na het weghalen van deze format wordt de tekst volledig weergegeven in access. Hieruit volgt een vraag, en heb ik ook al uitgebreid op gezocht maar niets gevonden. Is het mogelijk om in bulk deze notatie (of dus format in het engels) aan te passen voor alle longtexts?
Ons bedrijf maakt producten in flesjes, en deze flesjes krijgen een label. Omdat we in veel verschillende landen leveren, en veel verschillende producten maken, én in een aantal maatsoorten leveren, zijn er dus nogal wat combinaties mogelijk. Om deze combinaties overzichtelijk te maken waren er oorspronkelijk per product excelsheets, en is er later een access database aangelegd met daarin de teksten voor de labels. Ieder product is een tabel, met per rij een taal, en per kolom een zin. Degene die de database beheerd doet dit rechtstreeks in de tabellen.
Bijvoorbeeld:
Op rij 4 staat bijvoorbeeld de taal FR, en er zijn onder andere de kolommen SAMENSTELLING R1, SAMENSTELLING R2 enzovoort.
Vervolgens zijn er in onze labelsoftware (Nicelabel) per maatsoort labels gebouwd (bijvoorbeeld 1 LITER, 500 ML, etc), met daarin de opmaak, en per veld is een script die RTF tekst opbouwt en via SQL statements de benodigde velden uit de access database haalt.
Het probleem:
We lopen nu tegen het volgende probleem aan. De access database is samengesteld uit de voorgenoemde excelsheets. Deze zijn stuk voor stuk geimporteerd, iedere sheet werd een tabel. Dit leek allemaal ideaal, en werkte zeer snel. Na verloop van tijd kwam degene die teksten beheerde er achter dat sommige velden niet "compleet" waren, de tekst werd afgebroken. Op het label waren de teksten echter wel compleet, dus heel urgent was het niet. Nu blijkt dat voor sommige van deze velden op voor ons onverklaarbare wijze de tekst op de labels óók afgebroken wordt, en er dus max. 255 tekens uit de database gehaald worden. Uiteraard ben ik zelf op zoek geweest naar de oorzaak, en die is deels te vinden in het importeren van excel naar access, er blijkt dan truncation plaats te vinden, ook al staat het doelveld op longtext. Dit verklaard echter niet dat de tekst wél goed op het label kwam, en het veld dus "onderwater" wel degelijk meer dan 255 tekens bevatte...
Mijn vraag:
Hoe kan het dat velden, blijkbaar spontaan, ineens maar max. 255 tekens bevatten, terwijl dit hiervoor aantoonbaar niet zo was? Daarnaast, hoe kan ik dit in de toekomst voorkomen? Zoeken wijst uit dat bij de eigenschappen van een longtext veld schakelen van "tekst zonder opmaak" naar "tekst met opmaak" meer dan 255 tekens mogelijk maakt, maar ik heb dit nog niet in de productiedatabase geprobeerd, omdat ik niet weet hoe mijn labelsoftware hier mee om zou gaan, ik ga dit van de week proberen.
Update:
Kennelijk heeft het schrijven van deze post mijn gedachten weer enigszins op een rijtje gezet, want ik heb mogelijk de oorzaak gevonden. In de veldeigenschappen van een longtext (memo) kun je de notatie (format) bepalen. De stond voor alle geimporteerde velden op "@". Na het weghalen van deze format wordt de tekst volledig weergegeven in access. Hieruit volgt een vraag, en heb ik ook al uitgebreid op gezocht maar niets gevonden. Is het mogelijk om in bulk deze notatie (of dus format in het engels) aan te passen voor alle longtexts?
[ Voor 9% gewijzigd door Freggel_United op 19-09-2016 12:57 ]
By each crime and every kindness, we birth our future