__deets__ hat geschrieben: ↑Dienstag 20. Februar 2024, 17:14
Da JSON prinzipbedingt keine Binaerdaten enkodieren kann, hast du zwei Moeglichkeiten:
1) das Binary wird base64 oder vergleichbar als String kodiert, und muss dann client-seitig rekodiert werden.
2) was du selbst angedacht hast, Binaerdaten explizit auszuliefern.
Moeglichkeit 1 ist aufwendig und erhoeht die Datenmenge um ~25%. Darum wuerde ich zu zwei greifen.
Das mit der Convertierung mit base64 habe ich versucht. Hättest du da Beispiel-Code? Bei mir wollte dies nicht funktionieren. Eigentlich würde ich dies gerne machen, da ich die API noch für andere Anwendungen nutzen möchte. Leider habe ich es nicht geschafft, das ganze zum fliegen zu kriegen.
Die Binärdaten explizit ausliefern ist auch eine Möglichkeit. Ich werde es versuchen, allerdings habe ich dann zwei Arten von Endpunkten und ich muss immer unterscheiden. Wenn die API grösser wird, könnten dadurch Fehler entstehen. Deshalb favorisiere ich trotz deinem Abraten aktuell noch Möglichkeit 1.
P.S. im ursprünglichen Versuch konvertiere ich auf der SQL Seite das varbinary in varchar. Nun sollte es eigentlich reiner Text sein. Leider kommt die Fehlermeldung dann immer noch....
Sirius3 hat geschrieben: ↑Dienstag 20. Februar 2024, 19:30
Offensichtlich kann MSSQL keine JSON-Daten liefern. Denn sonst würde Python keinen Dekodierungsfehler werfen.
Da muss ich dir Recht geben. MSSql kann nur die Struktur des JSON imitieren. Wenn also Binary daherkommt, wird dieses einfach abgefüllt wie es in der Datenbank abgelegt ist. Es ist nicht eine Konvertierung zu JSON, sondern nur die Struktur. Die Konvertierung müsste man selber machen. Leider habe ich noch keine schlaue Antwort gefunden, auf was ich das varbinary convertieren soll, damit es JSON kompatibel ist. Ich habe auf SQL-Seite einiges versucht. Das Problem blieb aber bestehen.
Sirius3 hat geschrieben: ↑Dienstag 20. Februar 2024, 19:30
Warum überhaupt Json? Mach doch einfach eine ganz normale SQL Abfrage und dann hast du mit Binärdaten auch kein Problem.
JSON weil ich im echten leben noch verschiedene Lagerorte mitgebe. Da können pro Item mehrere vorhanden sein. Ich habe das SQL-Statement stark vereinfacht für diesen Eintrag. Ich muss aber eine Datenstruktur haben, die "Arrays" aufnehmen kann. Da aber MSSql mit JSON offensichtlich sehr schwach ist, muss ich dies vielleicht nochmal überdenken.
__blackjack__ hat geschrieben: ↑Dienstag 20. Februar 2024, 20:33
@rbaert: Nur um sicherzugehen, dass das Problem hier richtig lokalisiert wurde: Welches ist denn das Feld mit JSON? Oder anders: Welche Felder sind denn Zeichenketten? Nicht dass Du hier versuchst Description als JSON zu dekodieren, das JSON aber tatsächlich in Attachment steckt. Und welchen Typ hat Attachment auf Python-Seite? Eventuell ist das ja auch gar keine Zeichenkette sondern ein `bytes`-Objekt.
Wenn ich das richtig verstehe sind in der Description die Spaltennamen, etc. Da kommt von SQL ein kryptischer Feldnamen daher (weil ich ja auch keinen Namen mitgebe). Deshalb ignoriere ich den Feldnamen und nehme nur den Inhalt. Description ist das nicht, denn ich muss zugeben, dass ich dies am Anfang versucht habe. Aktuell bekomme ich die richtigen Werte zurück, wenn ich Attachment rausnehme funktioniert alles wunschgemäß. Attachment wäre innerhalb des JSON strings. Und nein, es ist kein 'bytes' es ist ein String, wenn auch mit kryptischen Zeichen darin.
sparrow hat geschrieben: ↑Dienstag 20. Februar 2024, 20:41
@rbaert: Es wirkt auch irgendwie komisch jedes Feld als JSON zu lesen. Muss das so? Ist nicht der komplette Response nicht ein JSON Objekt?
Ich habe mich am Anfang entschieden, dass alle Prozeduren aus SQL nur einen Wert und zwar ein JSON zurückgeben sollen. Faktisch bekomme ich eine Tabelle mit nur einer Spalte und nur einer Zeile zurück. Allerdings zweifle ich während ich diese Zeile schreibe auch daran ob dies der richtige Weg ist. Evtl. kann ich in der Prozedur kein Select ausführen, sondern ein Return. Das ist ein guter Input, danke. Bleibt aber immer noch das Problem mit der Konvertierung.