infra:NET Expert
 
×
04.14.1 Aufbau der Feldnamen
Die Datei SIBDD.NTB setzt sich aus folgenden Bestandteilen zusammen:
  • Tabellenüberschriften, zum Beispiel "TAB 006 Teilestammdatei"
  • Feldnummer mit Feldnamen, zum Beispiel "003 Teil"
Nach jeder Tabellenüberschrift folgen in einzelnen Zeilen die Feldnamen, so dass sich z.B. folgender Aufbau ergibt:
TAB 006 - Teilestammdatei
001 Stat
002 AendDat
003 Teil
...
Syntax Tabellenüberschriften: TAB Tabellennummer Kommentar
Die Tabellennummer muss dem Datei-Index laut DataDictionary entsprechen, zum Beispiel 006 für den Teilestamm (immer mit führenden Nullen angeben). Der Kommentar sollte die Dateibezeichnung enthalten, kann aber auch fehlen.
Syntax Feldnamendefinition: Feldnummer Feldname FF_NOSQL
Syntax Feldnamendefinition: Feldnummer Feldname FF_SQLFORMAT:Formatangabe
Die Feldnummer entspricht der Nummer im DataDictionary, zum Beispiel 003 für die Teilenummer im Teilestamm (immer mit führenden Nullen angeben). Die Feldnamen dürfen nur mit Buchstaben, nicht mit Ziffern beginnen und keine Leerzeichen enthalten. Auch Umlaute oder ß dürfen nicht verwendet werden. Die Namen müssen außerdem bei Verwendung mit einer SQL Server Datenbank den Regeln für die Feldnamen einer  SQL-Tabelle entsprechen. Detaillierte Informationen dazu sind in der "Microsoft SWL Server" Online-Dokumentation zu finden.
Die Angabe FF_NOSQL bedeutet, dass dieses Feld nur in der internen infra-Datenbank, jedoch nicht in einer beigestellten Microsoft SQL Server Datenbank vorhanden ist. Die Angabe darf nur von einem entsprechend geschulten Anwender benutzt werden. Bestimmte Felder der internen infra-Datenbank sind aus systemtechnischen Gründen "redefiniert", das heißt mehrere Felder referenzieren auf dieselben Feldinhalte. Zum Beispiel gibt es sehr oft den Fall, dass ein Feld mit 8 Stellen für das 8-stellige Datumsformat existiert und ein Feld, das nur auf die letzten 6 Stellen der Datumsangabe verweist. Solche Situationen werden auch ohne die Angabe FF_NOSQL für die SQL Server Datenbank nach folgendem Prinzip gelöst: In der SQL Server Datenbank ist immer nur das "überdeckende Feld" beschrieben. Die Felder, die die einzelnen Bestandteile beschreiben, werden dann ignoriert. Mit FF_NOSQL kann nun ein solches überdeckendes Feld von der Übergabe an die SQL Server Datenbank ausgeschlossen werden. Damit werden dann die Feldnamen der Bestandteile für die SQL Server Datenbank bereitgestellt.
Achtung
Die in der SQL Server Datenbank zur Verfügung gestellten Felder ändern sich zwar entsprechend der gesetzten (bzw. gelöschten) FF_NOSQL-Angabe unmittelbar bei der Erzeugung des Laufzeit-DataDictionaries mittels SIBDDGEN, aber es werden keine Feldinhalte für bisher nicht verfügbare Felder übernommen. Das heißt, wenn ein bisher in der SQL Server Datenbank zur Verfügung gestelltes „überdeckendes Feld“ einer Redefinition per FF_NOSQL ausgeschlossen und damit die (untergeordneten) Einzelfelder in der jeweiligen SQL Tabelle angelegt werden, sind diese zunächst ohne Inhalt und müssen durch eine Totalreplikation (entweder manuell oder durch Reorganisation der betroffenen infra-Datenbankdatei bei eingeschalteter Online-Replikation) gefüllt werden!
Mit der Angabe FF_SQLFORMAT:… kann das Format eines Feldes für die Repräsentation in der jeweiligen SQL-Tabelle abweichend vom Format in der infra-Datenbank angegeben werden. Das ist zum Beispiel dann sinnvoll, wenn ein C-Feld (alphanumerisches Feld) der infra-Datenbank SQL-seitig als numerisches Feld abgebildet werden soll. Im Standard wird diese Technik verwendet, um die Umrechnungsfaktor-Felder der infra-Datenbank, die jetzt als C12-Felder hinterlegt sind, auf der SQL-Seite als numerisches 10.6-Feld abzustellen.
Achtung
Die Umwandlung eines C-Feldes in ein numerisches SQL-Feld kann zu Problemen führen, wenn im betroffenen Feld bereits Daten gespeichert wurden, die keiner numerischen Darstellung entsprechen! Leerfelder der infra-Datenbank werden bei der Replikation (Online und Total) automatisch als 0 an die SQL-Datenbank übergeben. Bei der direkten Umwandlung der SQL-Datenbank per SIBDDGEN führen in der SQL-Datenbank zu einem Fehler und Abbruch der Konvertierung.
Hier helfen nur das Abschalten der Online-Replikation vor der Generierung des neuen DataDictionarys (SIBDDGEN) und eine anschließende Totalreplikation der angepassten Tabelle.
Beispiel: TAB 022 Bewegungsdatei
… …
029 UmrFakt FF_SQLFORMAT:DOUBLE(10,6)
… …