0x is een prefix voor binaire gegevens. Maar als er geen gegevens zijn dan is een lege string ('') voldoende voor een varbinary kolom. Alleen 0x is geen geldige hexadecimale literal, het proces dat de reservekopie heeft gemaakt, heeft dat niet goed gedaan, of de reservekopie is naderhand gewijzigd.
Als je deze query voert aan MariaDB:
SELECT 0x
Krijg je de foutmelding:
#1054 - Onbekende kolom '0x' in field list
Dus waarschijnlijk is de backup-tool die je gebruikt fout bezig geweest.
Met een beetje geluk kan je dat fixen door in de backup een zoek-en-vervang actie te doen van 0x naar ''.
[size=xsmall]Toevoeging op 12/12/2022 19:30:55:[/size]
J opla op 12/12/2022 17:33:25
Ik snap niet wat je bedoeld [sic], moet ik single quote om de integers en binary zetten? Dus ('1','0xhexgetal','0x',enz...)?
Om strings moeten altijd quotes, anders is het geen string literal. Als je op dezelfde manier van integers een string maakt, zal MySQL / MariaDB impliciet (zonder melding) naar een integer omzetten. Integers en andere numerieke literals hebben geen quotes, dus je kan ze bij nummers gewoon weglaten.
Om hexadecimale byte-reeksen (technisch ook 'strings') die beginnen met 0x, is het niet nodig om quotes te zetten. Wil je toch met quotes werken om waarden van binaire kolommen weer te geven, dan moet je dat weergeven als volgt:
x'01af'
Hexadecimale literals zijn ongevoelig voor hoofd- of kleine letters, het maakt niet uit wat je gebruikt.
Heel hartelijk bedankt voor de toelichting en de oplossingsrichting, het was inderdaad een kwestie van de 0x voor een lege cel te wijzigen in ''. De andere gegevens hoefden helemaal niet van single quotes te worden voorzien. Na de wijziging werkte de INSERT zoals je zou verwachten en kan ik weer inloggen in mijn site. Nogmaals, Dank voor jouw hulp!
