BafClientFmIni

Datenbanken einbinden mit den BafClientFM.ini

BAF kann verschiedene Datenbanken und verschiedene Datenbanksysteme einbinden. Dies erfolgt mit der Datei BafClientFM.ini, die im selben Verzeichnis liegen muss wie die BafClientFM.exe.

Eine Standard-Ini

In einem eher einfachen Fall sieht die BafClientFM.ini wie folgt aus:

[SYS]
ProgName=BAF Client FM
DCScale=100

[LOGIN]
username=admin
password=admin
scale=150

[DB]
count=2
default=0
db_1=db_dev
db_2=fb_dev

[DB_DEV]
Name=Entwicklungsdatenbank
DriverName=Sqlite
Database=db_dev.db
uProviderName=SQLite
so1=Direct=True
BG=303

[FB_DEV]
Name=Firebird Dev
DriverName=Firebird
Database=I:\Database\Firebird Database\FB_DEV.FDB
User=SYSDBA
Password=111woMAwrrCisK+w6NNb8Ks
uProviderName=InterBase
uServer=localhost
BG=303

Hier können wie folgenden Einstellungen vorgenommen werden:

[SYS]

• ProgName - Der Name des Programms wird in der Titelzeile des Hauptformulars angezeigt. Versionsnummer und Standard-Datenbank werden automatisch ergänzt. Der Name kann auch dazu verwendet werden, verschiedene Instanzen des BAF-Clients auseinander zu halten.
• DCScale - wird auf den Zoom-Slider ein Doppelklick ausgeführt, dann wird er auf diesen Wert eingestellt. Üblicherweise 100, also eine Skalierung von 100%.

[LOGIN]

• username - Mit diesem Wert wird der Username im Login-Dialog vorbelegt.
• password - Mit diesem Wert wird das Passwort im Login-Dialog vorbelegt. Für den produktiven Einsatz sollte dieser Wert entfernt und das ADMIN-Password entsprechend geändert werden.
• scale - Skalierung des Login-Dialogs. Wird üblicherweise etwas größer gewählt, damit bei hochauflösenden Bildschirmen der Login-Dialog gut zu erkennen ist.

[DB]

• count - Anzahl der hinterlegten Datenbanken
• default - 0-relativer Index der vorausgewählten Datenbank; mit dieser Datenbank wird die Datenbankauswahl-ComboBox des Login-Dialogs vorbelegt. Der Wert default=0 bedeutet, dass die Datenbank db_1 vorbelegt wird.
• db_1, db_2... - Die Kategorie-Bezeichnungen der einzelnen Datenbanken.

[DB_DEV]

Die Datenbank DB_DEV ist die Standard-Datenbank, die mit dem BAF-Client ausgeliefert wird.

• Name - Name der Datenbank, so wie sie in der Datenbankauswahl-ComboBox des Login-Dialogs angezeigt wird.
• DriverName - Name des Datenbanksystems
  • Sqlite
  • Firebird
  • Postgres
  • MySQL
  • Oracle (noch unvollständig eingebunden)
  • MSSQL (noch unvollständig eingebunden)
• Database - Name der Datenbank oder der Datenbankdatei. Wird bei SQLite kein Pfad angegeben, so muss die Datenbankdatei im selben Verzeichnis liegen wie BafClientFM.exe.
• User - Username (entfällt bei SQLite)
• Password - Password, in der Regel verschlüsselt (entfällt bei SQLite)
• uProviderName - Name des Datenbankproviders der UniDAC-Komponenten
  • SQLite
  • InterBase
  • PostgreSQL
  • MySQL
  • Oracle (noch unvollständig eingebunden)
  • SQL Server (noch unvollständig eingebunden)
  • (Die UniDAC-Komponenten unterstützen deutlich mehr Provider. Diese werden aber nicht offiziell unterstützt und sind auch nie getestet worden...)
• uServer - Name des Servers des Datenbankproviders der UniDAC-Komponenten (entfällt bei SQLite)
• so1, so2... ("SpecialOptions") - hier können SpecialOptions gesetzt werden, wie sie von Devart UniDAC verwendet werden. Gebräuchlich ist so1=Direct=True - damit brauchen bei Oracle und MS SQL-Server die Clients nicht installiert beziehungsweise bei SQLite die DLL nicht mitgeliefert werden, der erforderliche Code ist bereits in der Exe des BAF-Clients enthalten.
• BG - Generation des BAF-Clients. (Dient bei der Weiterentwicklung des BAF-Clients dazu, dass zum Beispiel Spaltenbezeichner geändert werden können und der Code trotzdem korrekt ausgeführt wird.)

DEV, TEST und PROD

Im Business-Umfeld wird gerne mit einer Trias von DEV, TEST und PROD gearbeitet (auch wenn das nicht immer exakt so benannt wird).

• DEV ist das Entwicklungssystem. Hier können die Entwickler auch mal $DINGE ausprobieren.
• TEST ist das Test-System. Hier wird fertig entwickelter Code von externen Softwaretestern (also nicht den Entwicklern selbst) getestet, bevor er produktiv geht.
• PROD ist das Produktiv-System

Die Entwickler müssen dann auf alle drei Systeme zugreifen können. Das könnte in der Ini-Datei wie folgt aussehen:

[DB]
count=3
default=2
db_1=db_prod
db_2=db_test
db_3=db_dev

[DB_PROD]
Name=Produktivdatenbank
DriverName=Sqlite
Database=I:\Code\BAF Client FM\DB SQLite\baf_db.db
zProtocol=Sqlite-3
uProviderName=SQLite
so1=Direct=True

[DB_TEST]
Name=Testdatenbank
DriverName=Sqlite
Database=I:\Code\BAF Client FM\DB SQLite\db_test.db
zProtocol=Sqlite-3
uProviderName=SQLite
so1=Direct=True

[DB_DEV]
Name=Entwicklungsdatenbank
DriverName=Sqlite
Database=I:\Code\BAF Client FM\DB SQLite\db_dev.db
zProtocol=Sqlite-3
uProviderName=SQLite
so1=Direct=True

Tipps für die Migration

Mit dem BAF-Client ist es relativ einfach, Code und Daten zwischen den einzelnen Versionen zu kopieren, sofern man das richtig angeht:

• Die CREATE TABLE-Skripte werden gleich in xdevtext angelegt. Änderungen (Ergänzungen von Spalten) werden dort stets sofort nachgezogen - damit hat man dann auch gleich die Vorlage, um sich den oder die Trigger (bzw. bei PostgreSQL die Funktion) generieren zu lassen.
• Sofern die CREATE TABLE-Statements aller hinzugekommenen Tabellen sauber vorliegen, lassen sich diese recht schnell auf der neuen Datenbank (TEST oder PROD) anlegen. (Mit etwas Routine schafft man etwa 3 Tabellen pro Minute; mit einem Script geht es noch schneller)
• Ob die Daten dieser Tabellen kopiert werden müssen, oder ob es sich um reine Testdaten handelt, die auf einem Produktivsystem nichts verloren haben, hängt vom Einzelfall ab. Oft müssen jedoch die Nachschlagelisten oder die Übersetzungen ergänzt werden - der Migrationsdialog bietet unter Data Migration das entsprechende Tool dafür.

Migration des Codes

Und dann muss der erstelle Code migriert werden. Hier gibt es zwei Möglichkeiten: Für die erste Migration - wenn also auf bestehenden Code noch keine Rücksicht genommen werden muss - bietet sich auch die Verwendung von Data Migration an. Soll zum Beispiel das Modul xlookup migriert werden, dann würde man das SQL-Statement dort wie folgt formulieren:

select * from sys_commands where name like 'xlookup%'

Damit erfasst man das Kommando und alle Sub-Kommandos und kann sie "in einem Rutsch" migrieren.

Migration ist nicht nur Erst-Migration, es müssen auch Weiterentwicklungen migriert werden. Hier verwendet man dann Code Migration und geht einzeln und die Kommandos und Sub-Kommandos. Code-Migration zeigt dabei die Unterschiede zwischen dem Code in der Quell- und der Ziel-Datenbank. Im Zeitdruck der Praxis werden häufig kleine Änderungen (Korrektur von Rechtschreibfehlern und Ähnliches) gleich auf dem Produktivsystem durchgeführt. Würde man jetzt von z.B. TEST nach PROD migrieren, wären solche alten Fehler wieder im Code. Von daher kann bei der Migration noch mal geschaut werden, welche Zeilen sich denn unterscheiden, und dann die Korrekturen erst mal in die Quell-Datenbank ergänzt werden, bevor die Migration vorgenommen wird.

Zusätzliche Datenbanken

Bislang haben wir nur die Primärdatenbank betrachtet, also die Datenbank, in der Code, Nachschlagelisten und auch sonst alles zu finden ist, was mit BAF zu tun hat. Meist muss man dann aber noch andere Datenbanken anbinden: Buchhaltung, DMS, CRM, was auch immer.

Das sieht in der Ini wie folgt aus:

[DB_PROD]
Name=Produktivdatenbank
DriverName=Sqlite
Database=I:\Code\BAF Client FM\DB SQLite\baf_db.db
zProtocol=Sqlite-3
uProviderName=SQLite
so1=Direct=True
adb_count=2
adb_1=db_fb_prod
adb_1n=firebird
adb_1a=N
adb_2=db_pg_prod
adb_2n=pg
adb_2a=Y

Mit adb_count ("additional database") wird angegeben, wie viele zusätzliche Datenbanken angelegt sind. Für jede dieser zusätzlichen Datenbanken gibt es drei Einträge (im Folgenden am Beispiel von asd_1):

• adb_1 - Kategorie der Datenbankeinstellungen in der Ini-Datei. mit adb_1=db_fb_prod lautet die Kategorie [DB_FB_PROD].
• adb_1n - Name der Datenbank im BAF-Code. Das ist getrennt, da bei DEV, TEST und PROD manchmal dieselben, manchmal abweichende Datenbanken eingebunden werden sollen, diese im Code aber immer gleich angesprochen werden sollen.
• adb_1a - Aktiv (Y oder N); häufig muss der Zugriff auf zusätzliche Datenbanken mal schnell abgeschaltet werden, zum Beispiel, wenn diese gerade nicht verfügbar sind. Mit diesem Ini-Eintrag kann das mit der Änderung eines einzelnen Zeichens (von Y auf N) erfolgen.

Hier im Beispiel ist die Datenbank pg / db_pg_prod aktiv. Vom Code aus kann darauf dann zugegriffen werden, indem der Parameter db gesetzt wird. Fehlt der Parameter db, so wird auf die Primärdatenbank zugegriffen.

#grd_data   q=sql   db=pg   t=data_list