ODBC 32bit Zugriff (KHKBoolean)

Bisut

Sehr aktives Mitglied
Ein Kunde von mir benötigt einen ODBC 32bit Zugriff für ein externes Programm um auf die Sage SQL Datenbank zugreifen zu können. Der Zugriff auf dem SQL Server ist vorhanden, das wurde bereits getestet. Der ODBC Zugriff auch. Zumindest kommt man an die Tabellen Werte im Lese Modus ran.

ABER:

Alle Tabellen die das Aktiv Kennzeichen haben, wie zum Beispiel Artikel, Kunden, Lieferanten - werden NICHT übermittelt. Das Kennzeichen wird irgendwie (warum auch immer) nicht mit in die ODBC Verbindungen übermittelt. Der Test wurde zum Beispiel in MS Excel nachvollzogen (ist dort das gleiche Problem).

Damit werden in dem Kundenbeispiel alle Artikel geladen, in dem externen Programm wird aber das Aktiv Kennzeichen gefiltert, das funktioniert aber nicht, weil das Kennzeichen aus der Sage Tabelle nicht mit übertragen wird.

Das Verhalten ist nicht nur im Kunden Datenbank, sondern in allen Sage Datenbanken der Fall. In meinem Test habe ich es ebenfalls nicht hinbekommen.

Jemand spontan Lust eine ODBC 32 bit Verbindung zur Sage DB zu schaffen? Und bitte mal prüfen ob Ihr das Nachstellen könntet?

Wichtig: Aber nicht den SA verwenden, der ist merkwürdigerweise Funktionsfähig.

Wir haben auch andere SQL Benutzer getestet, die haben gleiches Verhalten gezeigt.
 
Hallo,
meine spontane Vermutung dazu ist, dass der Datentyp des Aktiv-Kennzeichens Probleme bereitet. Für solche Ja/Nein-Schalter bzw. boolsche Werte nutzt Sage nämlich keinen nativen, sondern einen eigenen Datentyp namens "KHKBoolean". Funktionieren denn Filter auf andere boolsche Werte desselben Datentyps bzw. werden die Felder übertragen? Spontan fällt mir "IstVerkaufsartikel" im Artikelstamm als solches Feld ein.
 
Interessant, denn das Feld "IstVerkaufsartikel" ist auch vom Datentyp "KHKBoolean" [Info am Rande: KHKBoolean gibt nur die Werte "0" und "-1" für false und true vor - standardmäßig wären es "0" und "1"]:
1787031647509.png

Wird "IstVerkaufsartikel" in der ODBC-Verbindung in einen anderen Datentyp gewandelt? Dann könnte man das auch mit den Aktiv-Feldern machen. Oder gibt es andere Unterschiede zwischen "IstVerkaufsartikel" und den Aktiv-Feldern in der ODBC-Verbindung?
 
Stimmt: Alle KHKBoolean fehlen, das ist uns vorher gar nicht aufgefallen, Habe ich gerade geprüft.
 
Screenshot 2026-08-18 080102.jpg
Vielleicht gibt es einen Trick? Hier bei der Verbindung - möglicherweise ein SQL Anweisung die das filtern könnte?
 
Mit ODBC-Verbindungen arbeite ich so gut wie nie & habe jezt kein Zeit, mir das näher anzuschauen. Interessant fand ich, dass es mit dem User "SA" funktioniert. Soweit ich weiß ist der Datentyp "KHKBoolean" im SQL Server als eigenes Objekt (ähnlich einer Tabelle oder Prozedur) angelegt. Das legt die Vermutung nahe, dass der SA darauf Zugriff hat, anderen ODBC-Usern jedoch die Berechtigungen fehlen. Also vll. hier mal schauen? Alternativ fällt mir nur ein CAST in der SQL-Anweisung ein, aber dann müsste man jedes benötigte Feld manuell angeben.
 
Danke, ich hatte mich leider auf Kollegen verlassen, aber nein, SA geht auch nicht, auch SA wird Boolean abgefiltert. Die KI hatte mir auch das bestätigt. Dort Lösungsansatz für ein SQL Skript, das Boolean umwandelt in 0 oder 1; das kann ich persönlich aber nicht. Werde ich mir Hilfe also holen müssen. Hätte mal vorher die KI fragen sollen, da stand das Problem mit ODBC so bereits drin.
 
Moin, das ist mindestens ziemlich dubios. Ich kenne keine Anwendung die per ODBC mit den Datentypen Probleme hat, weil das eh nur ein Alias für Smallint ist. Da würden ja von heute auf morgen tausende Anbindungen an DPD und CRM und sonstige zerbröseln.
Zwei Empfehlungen: "GRANT VIEW DEFINITION TO LoginName" versuchen, LoginName ist natürlich der Benutzer für die ODBC Verbindung. Und wenn das nicht geht, die gewünschte Tabelle in einen View packen der den Typ explizit konvertiert: "Convert(smallint, Aktiv) AS Aktiv"

Ich habe das gerade aber mal parallel mit Excel und Word im Standard ohne Anpassungen oder Views mit einem reinen Datareader probiert per ODBC, und das klappt problemlos. Welchen ODBC SQL Treiber verwendet Ihr dafür?
 
Zuletzt bearbeitet:
Das Umwandeln der Basistabellen von KHKBoolean in Smallint hätte sage schon vor 20 Jahren mal machen können, weil bei solchen Dingen aber immer Seiteneffekte auftreten können, und der Typ ja normalerweise keinen Fehler auslöst, hat man es einfach so gelassen.
Den Typ droppen könnte man ja sowieso nicht, weil unzählige Sonderprogrammierungen auch diesen Datentyp verwenden.
 
Es wurden SQL Driver 17 und Driver 18 verwendet, beide haben aber gleiche Problem Ansonsten würde ich @planB gerne für Freitag kurz buchen wollen, da Freitag Zugriff auf den Kunden Server hätte, inklusive MS Excel eventuell auch MS Access, diesen Einsatz könnte ich dann an Kunden weiter berechnen. Ich war eigentlich nur für den SQL Server Zugriff zuständig, nicht für ODBC; das hat man mir aber mit übergeben, weil die externe Datenanbindungen mit ODBC Verbindungen diese Probleme führte und mich ansprachen, ob ich was falsch gemacht hätte. Aber 4 Augen sehen immer besser. Würde Sie dann gerne dazu Kontaktieren. Geht das bei Ihnen am Freitag?
 
Zurück
Oben