Eure proALPHA-Daten sollen ins Reporting, aber die ODBC-Abfrage liefert nichts? Das sind die Gründe

Von /

Das Controlling will die Lieferzuverlässigkeit über drei Jahre auswerten. Die IT richtet brav einen ODBC-Treiber ein, verbindet sich mit der proALPHA-Datenbank, setzt ein einfaches SELECT ab — und bekommt entweder keine einzige Zeile zurück oder einen Fehler über ein zu langes Feld. Niemand hat etwas falsch gemacht. Es ist nur so, dass proALPHA und seine Datenbank anders funktionieren als ein normaler SQL Server.

proALPHA ist ein starkes ERP für den industriellen Mittelstand. Stark in der Produktion, schwach in der freien Auswertung. Und die Datenbank darunter hat ein paar Eigenheiten, die man kennen muss, bevor der erste Bericht steht.

Was unter proALPHA wirklich liegt

proALPHA läuft auf dem Progress OpenEdge RDBMS. Das ist eine ausgewachsene relationale Datenbank, aber keine, die man wie einen Microsoft SQL Server behandeln kann. Einen MS-SQL-Server-Betrieb von proALPHA gibt es nicht; SQL Server ist hier immer nur das Zielsystem für Auswertung und DWH, nie das Quellsystem.

Der entscheidende Punkt, den die meisten Anleitungen verschweigen: Progress OpenEdge hat zwei getrennte Abfrage-Engines. Die eine ist ABL, früher 4GL genannt, mit der die proALPHA-Anwendung selbst arbeitet. Die andere ist eine SQL-92-Engine, über die ODBC und JDBC laufen. Beide greifen auf dieselben Daten zu, verhalten sich aber grundverschieden. Wer per ODBC an proALPHA will, spricht immer mit der SQL-92-Engine, nicht mit der Welt, in der die Anwendung lebt.

Genau aus dieser Trennung entstehen die drei typischen Hürden, an denen der Zugriff scheitert.

Hürde 1: Die SQL-Engine muss überhaupt laufen

ODBC erreicht nicht einfach die Datenbankdatei. Es spricht mit einem SQL-Broker, den die Datenbank im Sockets-Modus bereitstellen muss. Ist dieser Broker nicht konfiguriert und gestartet, gibt es schlicht nichts, womit sich der Treiber verbinden kann. Das ist eine Aufgabe für den Datenbankadministrator oder den proALPHA-Partner, kein Häkchen im ODBC-Dialog.

Hürde 2: SQL-Rechte sind standardmäßig gesperrt

Hier liegt der Grund, warum eine Verbindung oft steht, aber keine Zeilen liefert. Auf der ABL-Seite gilt: Alles ist erlaubt, die Anwendung regelt die Sicherheit. Auf der SQL-Seite ist es genau umgekehrt. Dort ist alles gesperrt, außer für den Eigentümer der Daten, und Zugriff muss ausdrücklich per GRANT erteilt werden.

Ein frisch eingerichteter ODBC-Benutzer sieht deshalb erst einmal nichts, bis ihm jemand auf der SQL-Ebene Leserechte erteilt. Wer das nicht weiß, sucht den Fehler im Treiber, obwohl er in den Berechtigungen liegt.

Hürde 3: Das SQL-WIDTH-Problem

Das ist die Hürde, die am meisten Zeit frisst und am wenigsten bekannt ist. In der ABL-Welt ist das Feldformat nur ein Anzeigehinweis. Ein Feld kann tatsächlich längere Werte enthalten, als sein Format vermuten lässt. Die SQL-92-Engine dagegen erzwingt eine feste Breite, die anfangs nur aus dem Format geschätzt wird.

Steht in einem Feld mehr, als diese geschätzte Breite zulässt, scheitert die SQL-Abfrage mit einem Breiten- oder Trunkierungsfehler. Das ist exakt der Fehler über zu lange Felder, den die IT am Anfang sieht.

Der offizielle Weg, das zu beheben, ist das Progress-Werkzeug dbtool. Es durchsucht die Felder, ermittelt die tatsächlich vorkommende maximale Länge und setzt die SQL-Breite entsprechend hoch. Das berührt nicht die Daten und nicht die ABL-Anwendung, sondern nur die SQL-Breiten-Metadaten im Schema.

Trotzdem ist hier Vorsicht angebracht, und das ist der ehrliche Teil: Mit dbtool fasst du die Schema-Metadaten eures Produktiv-ERP an. Für eine reine Auswertung ist der saubere Weg, auf einer zurückgesicherten Kopie der Datenbank zu arbeiten und dbtool dort laufen zu lassen, oder den proALPHA-Partner einzubeziehen. Auf dem Live-System ohne Backup und ohne Absprache loszulegen, ist keine gute Idee.

So sieht der Zugriff dann aus

Der ODBC-Zugriff läuft über die DataDirect-Treiber von Progress, die für lizenzierte OpenEdge-Installationen kostenlos verfügbar sind. Einmal eingerichtet, lässt sich die Quelle sowohl aus Access als auch aus dem SQL Server verknüpfen.

Aus dem SQL Server geht das per Linked Server auf die Progress-ODBC-Quelle. Das hier ist der Kern, der entscheidende Punkt steht im Kommentar:

-- Voraussetzung: SQL-Broker läuft, GRANTs gesetzt, SQL-Widths per dbtool geprüft.
-- Erst dann liefert OPENQUERY verlässlich Zeilen.
EXEC sp_addlinkedserver
    @server     = N'PROALPHA',
    @srvproduct = N'Progress OpenEdge',
    @provider   = N'MSDASQL',
    @datasrc    = N'proalpha_sql92_dsn';

-- Tabellen- und Feldnamen sind proALPHA-spezifisch und müssen aus dem
-- Datenmodell ermittelt werden. <Auftragstabelle> ist hier ein Platzhalter.
SELECT *
FROM OPENQUERY(PROALPHA, 'SELECT * FROM "<Auftragstabelle>" WHERE "Status" = ''aktiv''');

Ein wichtiger Hinweis zur Struktur: proALPHA verteilt seine Daten teilweise auf mehrere Progress-Datenbanken. JOINs über mehrere dieser Datenbanken hinweg waren über eine einzelne ODBC-Verbindung lange nicht möglich und sind erst ab neueren OpenEdge-Versionen wieder erlaubt. Wer mehrere Quell-Datenbanken hat, plant das besser über die Staging-Ebene im SQL Server, statt es in einer einzigen OPENQUERY erzwingen zu wollen.

Sobald die Daten als Datei oder über Staging im SQL Server liegen, ist der Rest Routine. Beim CSV-Import gilt:

BULK INSERT staging.proALPHA_Auftraege
FROM 'D:\proalpha_export\auftraege.csv'
WITH (
    FIELDTERMINATOR = ';',
    ROWTERMINATOR   = '0x0a',
    FIRSTROW        = 2,
    CODEPAGE        = '1252'   -- ältere Exporte sind codepage-basiert, nicht UTF-8
);

Der Weg über die Anwendung selbst

Wenn der direkte SQL-Zugriff zu heikel ist oder der Partner ihn nicht freigibt, bleibt der dokumentierte Weg über proALPHA selbst. Über definierte Berichte und den Batchserver lassen sich Aufträge, Lagerbewegungen, Stücklisten und OP-Listen als CSV oder Excel ausgeben. Das ist langsamer und weniger flexibel als direkter SQL-Zugriff, aber es kommt niemandem an die Live-Datenbank, und es ist vom Hersteller vorgesehen.

Wo der Weg an Grenzen stößt

Bei proALPHA ist nicht der Zugang das eigentliche Problem, sondern die Vorbereitung: SQL-Broker, Rechte, Feldbreiten. Sind diese drei geklärt, ist der Rest solides Handwerk. Sind sie es nicht, scheitert jede Abfrage, und der Fehler wird an der falschen Stelle gesucht.

Eine Randnotiz zur Aktualität: proALPHA bietet inzwischen eigene Integrations- und Web-Service-Komponenten an. Die pauschale Aussage „keine API“ trifft die modernen Versionen nicht mehr. Für die klassische On-Premises-Auswertung im Bestand bleibt der SQL-92-Zugriff aber der praktisch relevante Weg.

Was das für dich heißt, wenn du es nicht selbst baust

Für dich als Geschäftsführer oder Controller heißt das: Die proALPHA-Daten sind erreichbar, aber der Weg dahin hat drei Vorbedingungen, die nichts mit dem Reporting-Tool zu tun haben. Wer dir verspricht, Power BI sei „schnell mal angebunden“, hat weder den SQL-Broker noch die Berechtigungen noch die Feldbreiten angefasst — und genau daran scheitert es dann in der ersten Woche.

Der wirtschaftlich spürbare Unterschied liegt darin, dass eine einmal sauber aufgesetzte Anbindung danach jeden Monat ohne Handarbeit liefert, statt dass jemand jedes Mal Berichte aus proALPHA herausklickt und in Excel zusammensetzt.

Wenn du sowas im Bestand hast

Wenn bei euch proALPHA läuft und ihr verlässliche Auswertungen oder ein DWH daraus aufbauen wollt, lohnt sich, die drei Vorbedingungen — Broker, Rechte, Feldbreiten — vorab zu klären, am besten auf einer Kopie der Datenbank. Wer das einmal sauber aufsetzen lassen möchte, erreicht mich über ein kostenloses Erstgespräch.

Quellen

Über Sönke Schäfer

Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei der Anbindung von ERP- und Branchensystemen an SQL Server und Microsoft Access. Sein Schwerpunkt liegt darauf, aus gewachsenen Beständen wie proALPHA auf Progress OpenEdge verlässliche Auswertungen und Data-Warehouse-Strukturen zu bauen — ohne das laufende ERP zu gefährden. Büro in Sierksdorf, Ostholstein.

Ähnliche Beiträge

Nach oben scrollen