[NEWSboard IBMi Forum]
Seite 2 von 3 Erste 1 2 3 Letzte

Thema: DDS --> SQL

  1. #13
    Registriert seit
    Oct 2004
    Beiträge
    240
    Zitat Zitat von BenderD Beitrag anzeigen
    Aber im Vergleich RPG/Cobol mit Index sequentiellem Zugriff versus embedded SQL in RPG/COBOL (und darum gings in der Frage) würde ich das ein wenig anders akzentuieren:
    Ja, das habe ich etwas zu "stark vereinfacht" bzw. zu ungenau. Mit Einzelread meinte ich wirklich nur eine Leseoperation (keine Sequence), also z.B. die Bankbezeichnung aufgrund einer Bankleitzahl dazulesen. Die im SQL zu verhinderten n+1 Reads sind mit RPG/Cobol weniger dramtisch.

    Aber sobald es um mehrer Daten geht (eben auch einzeln per cursor) hat man mit SQL die Nase vorn.

    Noch ein Nachtrag zu SQL:
    Mit zunehmender Normalisierung der Datenbanken wird der konventionelle (RPG/Cobol, pures SQL) Weg auch immer mühsamer, da immer mehr Joins für das gleiche Ergebnis notwendig sind (im Vergleich zu weniger normalisierten Daten).

    /Robert

  2. #14
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Da gibts dann immer noch FETCH 1 ROW ONLY oder, wenn der Schlüssel (durch Integrität) tatsächlich eindeutig ist, kann ich mir den Cursor sparen und einen SELECT INTO verwenden, und der ist auch nicht langsamer als ein CHAIN/READ INVALID.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #15
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    genau dieser Einzelzugriff ist aber nicht SQL like, der gehört per Join (besser noch per View) in einen Join im Cursor rein. Die ganze Normalisierung gehört im View Layer (soweit möglich) wieder denormalisiert!
    Die Grenze findet das erst im Update (deshalb Datenbankzugriffsmodule, die das dann wieder auflösen) und bei verzweigten Objektbäumen, die sich nicht immer als flache Relation darstellen lassen.

    D*B

    Zitat Zitat von RobertPic Beitrag anzeigen
    Mit Einzelread meinte ich wirklich nur eine Leseoperation (keine Sequence), also z.B. die Bankbezeichnung aufgrund einer Bankleitzahl dazulesen.
    /Robert
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  4. #16
    Registriert seit
    Jul 2003
    Beiträge
    331

    Cool

    Wenn jemand seine Anwendungen (RPG) nicht grundlegend überarbeiten will, dann kann ich aus den Antworten auf meine Fragestellung (DDS/SQL) keinen Grund erkennen, warum die Tabellen von DDS auf SQL umgestellt werden solten.

    Auch ohne Umstellung können DDS-Dateien ja auch bei Bedarf mit SQL bearbeitet werden.

  5. #17
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... ich fühle mich da durchaus richtig interpretiert. Ich würde aber vehement empfehlen alles, was man neu macht, nach neuem Standard zu entwickeln. Sprich: weg von RLA und DDS zu SQL. Sobald man sich in der neuen Denke heimisch fühlt, wird man auch einiges, was man ändert umstellen und alles was Läuft, das läuft: never run a achanging system.

    D*B

    Zitat Zitat von loeweadolf Beitrag anzeigen
    Wenn jemand seine Anwendungen (RPG) nicht grundlegend überarbeiten will, dann kann ich aus den Antworten auf meine Fragestellung (DDS/SQL) keinen Grund erkennen, warum die Tabellen von DDS auf SQL umgestellt werden solten.

    Auch ohne Umstellung können DDS-Dateien ja auch bei Bedarf mit SQL bearbeitet werden.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #18
    Registriert seit
    Oct 2004
    Beiträge
    240
    BenderD
    genau dieser Einzelzugriff ist aber nicht SQL like, der gehört per Join (besser noch per View) in einen Join im Cursor rein.
    Ja das ist schon klar wie man das mit SQL macht. Ist eigentlich noch ein Grund gegen eine Umstellung. Für die optimale Performance genügt es nicht einfach die Dateioperationen 1:1 umzusetzen, sondern mehrere READ's per Join zusammenzufassen.

    Fuerchau
    und einen SELECT INTO verwenden, und der ist auch nicht langsamer als ein CHAIN/READ INVALID.
    Mein Eindruck wahr eher "gefühlt" als gemeesen (drum auch mMn). Die n+1 Problematik dürfte wohl eher bei JDBC/ODBC (wg. Netzerkoverhead) zum Problem werden.

    Was noch bleibt, ist, dass bei SQL die Felder noch gemappt werden müssen. Zumindest in Cobol gibt es kein Mapping, da wird der ganze Record verschoben (auch wenn's Müll ist).

    @loeweadolf
    Ein paar Vorteile (Datei ändern ohne Levelcheck, gleiche Indexe für RPG und SQL) gibt es schon - aber keiner rechtfertigt (für sich alleine) eine Umstellung.

    /Robert

  7. #19
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Zitat Zitat von loeweadolf Beitrag anzeigen
    Was ist denn eigentlich der entscheidende Vorteil, wenn DDS-Dateien geändert werden in SQL-Tabellen ?

    Bei Zugriff aus RPG-Programmen vermutlich kein Vorteil ??

    Bei Zugriff über Embedded SQL ? evtl. bessere Zugriffszeit ?

    In DDS-Quellen sind Dateien nach meiner Meinung zuindest besser zu dokumentieren.
    Ich würde empfehlen den folgenden Artikel von Dan Cruikshank zu lesen:
    Modernizing Database Access
    The Madness Behind the Methods


    Ein anderer Grund warum man sich langsam aber sicher von DDS verabschieden sollte ist, das DDS seit Release V4R5 "stabilisiert" ist. Sämtliche Neuerungen sind seither nur noch in die SQL DDL (Data Definition Language) eingeflossen, z.B. Identity Columns (V5R1), neue Datentypen (LOBs, DecFloat, RowId), Hidden Columns und automatische Aktualisierung von Zeitmarken-Feldern, bei Änderung des Datensatzes (6.1) ...

    Auf alle Fälle sollte man, bei Umstellung auf SQL eine separate Spalte mit einem eindeutigen künstlichen Schlüssel (ob dieser als Identity Column definiert oder andersweitig ermittelt wird, sei dahingestellt) hinzufügen und diesen Schlüssel als Primary Key definieren. Dadurch können auf alle Fälle Zugriffe über die relative Satz-Nr. vermieden werden und auch bei Tabellen, bei denen kein eindeutiger Schlüssel definiert werden kann (z.B. Bewegungsdateien) schnell und direkt zugegriffen werden. (Beim Zugriff über die relative Satz-Nr. über SQL wird in der CQE immer ein Table Scan ausgeführt, bei Zugriff über die SQE eine Table Probe, was zwar gegenüber dem Table Scan schneller ist, aber lange nicht optimal ist.)

    Ab 6.1 sind DDS beschriebenen logische Dateien nur noch bei geschlüsselten Join-Files, auf die über Native I/O zugegriffen werden muss, notwendig. Alles andere, sprich Feldselektion bzw. Erstellung von zusätzlichen Spalten, Select/Omit-Anweisungen und Schlüssel-Definition (auch über die zusätzlichen Spalten) kann über einen SQL-Index abgedeckt werden. Übrigens, von diesen Neuerungen in 6.1 kann bislang fast nur der native I/O profitieren, SQL-Abfragen können bis dato diese neuen Indices noch nicht optimal nutzen.

    Was die Verwendung von komplexen logischen Dateien in Verbindugn mit "dynamischem" SQL angeht:
    Der Query-Optimizer (unabhängig davon, ob das SQL-Statement dynamisch oder statisch gebildet wird) über geht logische Dateien, die mit DYNSLT oder mit Access Path Maintenance *REBLD definiert wurden. Wird eine solche komplexe logische Datei in einem SQL-Statement angegeben, fackelt der CQE-Optimizer nicht lange und verwendet eine solche Datei, ohne auf die Keys Rücksicht zu nehmen (der SQE-Optimizer kann eh' keine DDS-beschriebenen logischen Dateien verarbeiten.)

    Übrigens ab 6.1 kann ein SQL-Index auch einen von der physischen Datei (oder SQL-Tabelle) abweichenden Format-Namen haben.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  8. #20
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    @Artikel: wenn man den Artikel genauer analysiert, dann fällt auf, dass da read Zeiten von 2 bis 3 milliSec gemessen werden (updates entsprechend länger etc.), das spricht nicht für Produktionsreife Hardware. Ich bleibe dabei: im richtigen Leben ist das unter der Messbarkeitsschwelle!

    Der Artikel ist eine Art Preview des dort angeführten Redbooks, das sich mit Modernisierung des Datenbankzugriffs beschäftigt. Beide Quellen sehen dort einen mehrstufigen Prozess vor, der letztlich bei einer Ablösung von DDS und RLA durch SQL DDL und embedded SQL endet. Ich denke, dass sich da eigentlich alle Experten (Birgitta, Robert, Baldur, D*B...) einig sind, dass das von Vorteil ist.

    Unterschiedlich eingeschätzt wird die Frage, womit man beginnt, der Artikel und das Redbook sehen da eine 1 zu eins Migration der Tabellen von DDS nach SQL DDL als ersten Schritt (auf dem dann viele hängen bleiben), ich vertrete eher die Position, dass man mit der funktionalen Ebene anfangen sollte, sprich der Herauslösung einer Datenbankzugriffsschicht mit nachfolgender Umstellung von ISAM auf Mengen orientierten Zugriff. Das wesentliche Argument hierfür ist, dass man auf diesem Weg eher Freiheitsgrade für Änderungen am Datenbankaufbau gewinnt und in der mitlleren Perspektive Programmier Aufwand spart (das halte ich für wichtiger als die Einsparung von CPU Sekunden). Technisch gesehen wird diese Vorgehensweise gestützt dadurch, dass SQL besser auf DDS Dateien zugreifen kann, als RLA uf eine reine SQL DDL Welt.

    Was die V6R1 Erweiterungen von SQL DDL auf System i (BKA AS/400) angeht, da sehe ich den Weg weg von ANSI SQL zu einem iSQL (BKA SQL/400) eher negativ und rate eher dazu nicht ANSI Features von SQL zu meiden.

    D*B



    Zitat Zitat von B.Hauser Beitrag anzeigen
    Ich würde empfehlen den folgenden Artikel von Dan Cruikshank zu lesen:
    Modernizing Database Access
    The Madness Behind the Methods


    Ein anderer Grund warum man sich langsam aber sicher von DDS verabschieden sollte ist, das DDS seit Release V4R5 "stabilisiert" ist. Sämtliche Neuerungen sind seither nur noch in die SQL DDL (Data Definition Language) eingeflossen, z.B. Identity Columns (V5R1), neue Datentypen (LOBs, DecFloat, RowId), Hidden Columns und automatische Aktualisierung von Zeitmarken-Feldern, bei Änderung des Datensatzes (6.1) ...

    Auf alle Fälle sollte man, bei Umstellung auf SQL eine separate Spalte mit einem eindeutigen künstlichen Schlüssel (ob dieser als Identity Column definiert oder andersweitig ermittelt wird, sei dahingestellt) hinzufügen und diesen Schlüssel als Primary Key definieren. Dadurch können auf alle Fälle Zugriffe über die relative Satz-Nr. vermieden werden und auch bei Tabellen, bei denen kein eindeutiger Schlüssel definiert werden kann (z.B. Bewegungsdateien) schnell und direkt zugegriffen werden. (Beim Zugriff über die relative Satz-Nr. über SQL wird in der CQE immer ein Table Scan ausgeführt, bei Zugriff über die SQE eine Table Probe, was zwar gegenüber dem Table Scan schneller ist, aber lange nicht optimal ist.)

    Ab 6.1 sind DDS beschriebenen logische Dateien nur noch bei geschlüsselten Join-Files, auf die über Native I/O zugegriffen werden muss, notwendig. Alles andere, sprich Feldselektion bzw. Erstellung von zusätzlichen Spalten, Select/Omit-Anweisungen und Schlüssel-Definition (auch über die zusätzlichen Spalten) kann über einen SQL-Index abgedeckt werden. Übrigens, von diesen Neuerungen in 6.1 kann bislang fast nur der native I/O profitieren, SQL-Abfragen können bis dato diese neuen Indices noch nicht optimal nutzen.

    Was die Verwendung von komplexen logischen Dateien in Verbindugn mit "dynamischem" SQL angeht:
    Der Query-Optimizer (unabhängig davon, ob das SQL-Statement dynamisch oder statisch gebildet wird) über geht logische Dateien, die mit DYNSLT oder mit Access Path Maintenance *REBLD definiert wurden. Wird eine solche komplexe logische Datei in einem SQL-Statement angegeben, fackelt der CQE-Optimizer nicht lange und verwendet eine solche Datei, ohne auf die Keys Rücksicht zu nehmen (der SQE-Optimizer kann eh' keine DDS-beschriebenen logischen Dateien verarbeiten.)

    Übrigens ab 6.1 kann ein SQL-Index auch einen von der physischen Datei (oder SQL-Tabelle) abweichenden Format-Namen haben.

    Birgitta
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  9. #21
    Registriert seit
    Mar 2019
    Beiträge
    33
    Zitat Zitat von BenderD Beitrag anzeigen
    @Artikel: wenn man den Artikel genauer analysiert, dann fällt auf, dass da read Zeiten von 2 bis 3 milliSec gemessen werden (updates entsprechend länger etc.), das spricht nicht für Produktionsreife Hardware. Ich bleibe dabei: im richtigen Leben ist das unter der Messbarkeitsschwelle!

    Der Artikel ist eine Art Preview des dort angeführten Redbooks, das sich mit Modernisierung des Datenbankzugriffs beschäftigt. Beide Quellen sehen dort einen mehrstufigen Prozess vor, der letztlich bei einer Ablösung von DDS und RLA durch SQL DDL und embedded SQL endet. Ich denke, dass sich da eigentlich alle Experten (Birgitta, Robert, Baldur, D*B...) einig sind, dass das von Vorteil ist.

    Unterschiedlich eingeschätzt wird die Frage, womit man beginnt, der Artikel und das Redbook sehen da eine 1 zu eins Migration der Tabellen von DDS nach SQL DDL als ersten Schritt (auf dem dann viele hängen bleiben), ich vertrete eher die Position, dass man mit der funktionalen Ebene anfangen sollte, sprich der Herauslösung einer Datenbankzugriffsschicht mit nachfolgender Umstellung von ISAM auf Mengen orientierten Zugriff. Das wesentliche Argument hierfür ist, dass man auf diesem Weg eher Freiheitsgrade für Änderungen am Datenbankaufbau gewinnt und in der mitlleren Perspektive Programmier Aufwand spart (das halte ich für wichtiger als die Einsparung von CPU Sekunden). Technisch gesehen wird diese Vorgehensweise gestützt dadurch, dass SQL besser auf DDS Dateien zugreifen kann, als RLA uf eine reine SQL DDL Welt.

    Was die V6R1 Erweiterungen von SQL DDL auf System i (BKA AS/400) angeht, da sehe ich den Weg weg von ANSI SQL zu einem iSQL (BKA SQL/400) eher negativ und rate eher dazu nicht ANSI Features von SQL zu meiden.

    D*B
    Ich muss bezüglich ANSI SQL und SQL/400 wiedersprechen.
    Jedes Datenbanksystem (OracleDB, MySQL, Microsoft SQL Server, PostgreSQL, DB2, etc) und natürlich auch DB2 for IBM i oder DB2/400 oder auch DB2 z/OS hat so seine Eigenheiten.
    Mit ANSI SQL ist der Teil von SQL definiert, der in allen Datenbanksystemen verstanden wird. ANSI SQL macht aber nur Sinn wenn man von der IBM i Abschied nehmen will. Ansonsten ist SQL/400 auf DB2/400 abgestimmt und agiert performanter. Das gleiche gilt übrigens für JAVA-Applikationen. Auch hier gibt es eine JAVA-Version, die auf das System abgestimmt ist.
    Was die Umstellung anbelangt, so gehe ich grundsätzlich wie folgt vor:
    Ich definiere die alten DDS-Dateien in SQL neu, mit langen, ausführlichen Spaltennamen und dem Systemnamen als alten Feldnamen (column name [alter Feldname]).
    Die Tabelle bekommt einen sprechenden langen Tabellennamen und einen klar definierten Systemnamen (10 Stellen). Z.B. XXYYY0000T wobei XX für den Fachbereich steht und YYY nach IBM-Konventionen aus dem Tabellen-Langnamen zusammengestellt wird. Beispiel: Tabellen-Langname automatic_processing würde bei mir, aufgrung der Tatsache, das es sich um eine IT-Interne Tabelle handet mit IT beginnen und dann um APR und 0000 für die alte physische Darstellung (Basistabelle) und T für Tabelle erweitet.
    Der Systemname lautet also ITAPR0000T.
    In SQL lautet es dann:
    create table automatic_processing_0 for system name ITAPR0000T(automatic_processing_ID for column APRID bigint generated by default as identity primary key,
    spalten_name1 for column FELD01 char(5) not null default '', .....);
    Bei der Vergabe der langen Namen ist darauf zu achten, dass dieser mehr als 10 Stellen aufweist, da man ja einen Systemnamen für die Tabelle selber vergeben und den alten Feldnamen als Spaltennamen setzen will.
    Es wird grundsätzlich eine neue ID-Spalte definiert (wenn nicht schon vorhanden), die nichts mit der Fachlichkeit zu tun hat und systemgeneriet wird (generated by default as identity primary key).
    Diese ID setze ich i.d.R. als erste Spalte der Tabelle.
    Die Übernahme der Daten aus der alten DDS-Datei wird mit einem SQL-Insertstatement erledigt, dass die ID-Spalte weg lässt.
    insert into table_name_0(spalten_name1, spalten_name2, ..., letzter_spalten_name) select FELD01, FELD02, ..., FELDXX) from [DDS-DATEINAME];
    Durch diesen Insert bekommt jeder Satz eine neue (technische) ID.
    Jetzt kann ich die DDS-Datei löschen und die dazugehörige DDS-Beschreibung (PF) in eine Logische wandeln.
    Die alte Record-Beschreibung muss dann auf die neue Tabelle mit dem Systemnamen verweisen.

    Beispiel:
    __________________________________________________ ________________________________
    A R RECORD TEXT('Satznamen Beschreibung')
    A PFILE(XXYYY0000T)
    A FELD01 COLHDG('FELD01')
    A FELD02 COLHDG('FELD02')
    A DATE01 COLHDG('DATE01')
    A TEXT('Datum in *EUR')
    A DATFMT(*EUR)
    A TIME01 T TIMFMT(*HMS) TIMSEP(':')
    __________________________________________________ ________________________________
    Hierdurch kann die, bisherige physische Datei im CL/RPG/COBOL wie bisher verwendet werden.
    Jetzt müssen noch die logischen Sichten angepasst werden:
    __________________________________________________ ________________________________
    A UNIQUE
    A R RECORD PFILE(XXYYY0000T)
    A FORMAT(ALTNAMEP)
    A K FELD01
    A K FELD02
    __________________________________________________ ________________________________

    Bevor diese erzeugt werden können muss natürlich die neue logische Sicht, die aus der alten physischen Beschreibung erzeugt wurde, erstellt werden, da die bisherigen Logischen auf diese Satzbeschreibung (FORMAT) verweisen.
    Da die Logischen kein Index sind, ist es ratsam die Schlüssel auch für die Erzeugung vom Index zu verwenden, also
    create unique index automatic_processing_index_0001 for system name ITAPR0001I on automatic_processing_0(FELD01, FELD02);
    Achtet darauf, dass die Angabe unique auch im entsprechenden Index verwendet wird, damit die Definition erhalten bleibt, wenn die Logische gelöscht wird.
    Für die Verwendung der Tabele solltet ihr noch eine 1:1 View erzeugen:
    create view automatic_processing for system name ITAPR0000V(select * from automatic_processing_0);
    Diese View ist die erste Zugriffsdefinition für Select's.
    Um die Tabelle in neuen Programmen zu verwenden und ohne großen Aufwand Sätze schreiben zu können definiert ihr noch eine View, die nicht die ID beinhaltet. Auch diese ist, was die Satzauswahl angeht eine 1:1 View.
    create view automatic_processing_0001 for system name ITAPR0001V(select spalten_name1, spalten_name2, ..., letzter_spalten_name from automatic_processing_0);
    jetzt könnt ihr Insert's tätigen ohne die ID manuell vergeben zu müssen.
    Last edited by Lucky662; 26-04-19 at 15:34. Grund: Formatierung, Rechtschreibung

  10. #22
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... diesen Verhau durfte ich mir letztens mal bei einem Kunden ansehen, dem man so ein Projekt flächendeckend aufgeschwatzt hatte. Alle Altprgramme verwendeten nach wie vor DDS LFs, was sonst bei RLA. Die Join Beziehungen gingen notgedrungen stets auf die alten Keys - die automatisch erzeugten hingen nebendran und waren für die Programme nicht sichtbar. In Altprogrammen gab es Zweige, wo ein Satz gelöscht wurde und unter bestimmten Konstellationen dann derselbe wieder eingefügt wurde, der dann einen neuen Primary Key bekam, was die Altprogramme nicht merken konnten - aber neu gebaute Schnittstellen.
    Neue SQL basierte Schnittstellen, die remote Daten replizierten, verwendeten ellenlange SQL Statements, um minimale Mengen an Nutzdaten zu transportieren.
    Die Programme hat man dann auch noch "modernisiert" und Hardcore RPG Programme automatisch nach **Free umgesetzt, hat sich dann aber nicht getraut das auch alles neu zu wandeln und in Produktion zu setzen (weil man sich nicht sicher war, dass alle Quellen wirklich aktuell waren), das macht man jetzt so nach und nach bei anstehenden Programmänderungen.
    Für Modernisierung des Knowhows der Mitarbeiter war kein Geld mehr da, ist jetzt ja auch alles neu.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  11. #23
    Registriert seit
    Mar 2019
    Beiträge
    33
    ...wenn man das Glück hat in einer Firma zu arbeiten, wo man alles auf der Grünen Wiese neu machen darf...

  12. #24
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Lucky662 Beitrag anzeigen
    ...wenn man das Glück hat in einer Firma zu arbeiten, wo man alles auf der Grünen Wiese neu machen darf...
    ... in meiner Firma darf ich alles, ich bin Freelancer!

    Ich habe häufig genug mit Firmen zu tun, die auf bewährter (man könnte auch ältlicher sagen) RPG Software hocken und damit nicht mehr recht weiter kommen. Oft werden dann komplette Subsysteme dazu genommen (nicht jeder kann oder will SAP einführen), die auf Windows oder Linux laufen und andere Datenbanken benutzen, oft MS SQL Server oder MySQL, manchmal Oracle oder was anderes. Das macht meist auch Sinn, sei es weil man fusioniert hat oder auch weil es kostengünstig ist und gut passt. Der Kontakt zu diesen Kunden kommt dann meist über ArdGate zustande, weil man nach Möglichkeiten sucht, die Subsysteme möglichst synchron an die RPG Anwendung anzukoppeln und Daten-mäßig zu vernetzen.

    Ich bin seit Jahren in den Bereichen Schulung tätig und habe auch Projekte zum Übergang auf neue Technologien begleitet und sehe da gewisse Prioritäten auf diesem Weg, wobei es da keine Patentrezepte gibt und das auch nicht in einem Forum erschöpfend behandelt werden kann.

    - Weiterentwicklung des Knowhows geht immer vor Aktionismus!
    - Jeder Schritt muss für sich genommen einen feststellbaren Nutzen haben!
    - Es muss eine klare, positiv formulierte Zieldefinition geben!
    - In den Bereichen Datenbank und Kommunikationsprotokolle gibt es etablierte Standards!

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

Similar Threads

  1. Umstellung von DDS auf SQL
    By bie-dro in forum NEWSboard Programmierung
    Antworten: 14
    Letzter Beitrag: 14-09-07, 15:17
  2. Befehl zum Konvertieren DDS in SQL
    By deni87991 in forum IBM i Hauptforum
    Antworten: 6
    Letzter Beitrag: 31-08-06, 13:05
  3. SQL -> CREATE VIEW
    By Kaufmann in forum IBM i Hauptforum
    Antworten: 17
    Letzter Beitrag: 11-05-06, 15:57
  4. QUERY --> SQL
    By redsky in forum NEWSboard Programmierung
    Antworten: 1
    Letzter Beitrag: 17-10-05, 12:23
  5. MS Sql Server + iSeries -> Verbindungsserver
    By reraru in forum NEWSboard Programmierung
    Antworten: 13
    Letzter Beitrag: 20-04-05, 14:07

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •