Die bei unserem Kunden eingesetzte Software wurde bereits in einem vorangegangenen Migrationsworkshop von der Version Team Developer 1.5 auf die Version Team Developer 6.0 migriert. Da eine Umsetzung als .NET-Applikation angestrebt wurde. Es wurde die .NET-Fähigkeit der Software-Lösung gewährleistet.
Daher ist zur Zeit die Software in den Versionen 1.5 und 6.1 im Einsatz, was zu einem erhöhten Wartungsaufwand führt, da Änderungen meist in beiden Ständen durchgeführt werden müssen.
Ziel ist daher, einen Programmstand in der Version Team Developer 6.1 zu erhalten.

Inhalt des Workshops:
Hauptschwerpunkte lagen in der Beseitigung von Fehlverhalten des Programmes im täglichen Einsatz:

• Im MDI-Window werden keine Scrollbalken angezeigt, wenn das Child-Window größer als der Clientbereich ist. Ein Testprogramm zeigte, dass die Ursache nicht im Team Developer begründet liegt. Ein Test im Team Developer 6.2 funktionierte einwandfrei, so dass hier nicht weiter analysiert wurde.
• Anzeige eines doppelten Fensters beim Start des EDIFACT-Prozesses. Das Fenster wurde bei Owner hWndForm angezeigt, allerdings 2 mal. Bei Owner hWndMDI wurde es erstellt, lag allerdings hinter dem aufrufenden Fenster und konnte auch nicht in den Vordergrund geholt werden. Ursache war hier eine vorher durchgeführte Änderung im Framework. Dies musste nun für diesen Prozess ebenfalls angepasst werden, d.h. die Owner der erstellten Fenster wurden korrigiert.
• Flackern des MDI-Menüs beim Öffnen und Schließen von Child-Fenstern. Anfrage an den Gupta-Support, ob hier eine bessere Möglichkeit besteht, ein dyn. Menü am MDI anzuzeigen.
• Bei Verwendung einer C#-Dll wurde innerhalb der TD-DIE ein Fehler angezeigt. Grund dafür war der Umstand, dass das Projekt auf einem Netzlaufwerk angelegt war. Befindet sich das Projekt auf einem lokalen Laufwerk, funktioniert alles einwandfrei.
• VisTblFindString führt keine exakte Suche durch – Meldung an den Gupta-Support.

Tool-Umstellung:

• Die beiden Tools „Table Builder“ und „Field Wizard“ (beides CDK-Tools zur Unterstützung einer einheitlichen Source- und GUI-Gestaltung) wurden von der Version Team Developer 1.5 auf die Version Team Developer 6.1 migriert.
• Anpassungsbedarf bestand bei der Erstellung von Background-Items.
• Probleme traten hier in der Version Team Developer 6.1 auf, da hier die Zuweisung der zugrundeliegenden DIE-Outline nicht funktionierte. Ein Test zeigte, dass dies in der Version Team Developer 6.2 behoben wurde und dort die beiden Tools funktionierten.
  Meldungen an den Gupta-Support:
  Problem mit der Funktion cdkI-tem.GetPrevSibling, wenn das zurückliegende Item ein Comment oder Background-Item ist.

Ergebnis:
Eine komplette Umstellung auf Team Developer 6.2 wird angestrebt.

Die Gupta SQLBase war die erste Client-/Server-Datenbank für Intel-Prozessoren, also für das Microsoft-Betriebssystem Windows, entwickelt von Umang Gupta, dem Gründer des gleichnamigen Unternehmens und vormaligen Projektleiter bei Oracle.

Das ist mittlerweile ca. zwei Jahrzehnte her und in dieser Zeit hat sich die SQLBase als ein sehr leistungsfähiges Datenbank-Managementsystem etabliert, das schnell zu installieren und einfach zu konfigurieren ist, das mit vergleichsweise geringen Ressourcen auskommt und über viele Jahre nahezu wartungsfrei läuft. Den gestiegenen Anforderungen wurde nach und nach mit neuen Versionen mit neuen Features Rechnung getragen.

So weit, so gut. Doch mit den Jahren wachsen auch die Datenbestände, die Zahl der zu bedienenden Anwendungen nimmt zu, und es werden auch immer mehr Anwender, die die Datenbank benutzen. Und so kann auch eine SQLBase-Installation an ihre Grenzen stoßen, wenn auf diese geänderte Umwelt nicht rechtzeitig und angemessen reagiert wird.

Manche bis dato zufriedene SQLBase-Anwender neigen dann dazu, das Kind mit dem Bade auszuschütten und nach einem anderen Datenbanksystem zu rufen – einer Entscheidung mit sehr weit reichenden Konsequenzen (nicht nur finanzieller Natur), die in vielen Fällen gar nicht notwendig gewesen wäre, hätte man zunächst die Möglichkeiten der SQLBase ausgereizt.

Folgende Ursachen für Problembereiche können genannt werden:

• Nutzeranzahl: Die Anzahl der gleichzeitig arbeitenden Anwender, Prozesse und Geräte kann sich im Laufe der Zeit wesentlich erhöht haben. Gupta Technologies nennt eine Größe von circa 100 als Zielgruppe für sein Datenbanksystem SQLBase.
• Sperrmechanismen im Mehrbenutzerbetrieb: Obwohl SQLBase sowohl „optimistic“ als auch „pessimistic locking schemes“ unterstützt, war die Implementierung dieser Mechanismen bis zu der letzten Version nur suboptimal gelöst. Als Folge davon konnten länger dauernde Transaktionen dazu führen, dass eine Vielzahl von Anwender keinen Datenzugriff mehr hatten.
• Datenvolumen: Das gespeicherte und zu verarbeitende Datenvolumen kann sich durch zusätzliche Nutzer, neue Nutzungsbiete, Import- und Exporttabellen, usw. teilweise dramatisch erhöht haben. In diesem Bereich ist Gupta Technologies aufgrund von sehr unterschiedlichen Datenmodellen, die implementiert sein können, nicht sehr spezifisch. Datenbanken, die eine Größe von 5 GByte überschreiten, sind aber potentiell problematisch anzusehen. Aufgrund recht einfacher Organisation der physischen Datenstrukturen (Row- und Extent Pages) bietet SQLBase zudem auch nicht so viele Möglichkeiten wie das Datenbanksystem von MS SQL Server.
• Parallele Batch- und Dialogbearbeitung: Viele Datenbanknwendungen sind dadurch gekennzeichnet, dass bestimmte Verarbeitungen im Dialog über eine GUI vorgenommen werden, während andere Verarbeitungsschritte beispielsweise durch gespeicherte Prozeduren ausgeführt werden. Ab einer bestimmten Größenordnung und Ausführungsdauer können sich derartige Prozesse bei SQLBase miteinander beeinflussen, dass Performance-Einbußen bis hin zu langen Sperrzeiten auftreten.
• Technische Erweiterungen: Um derartige Probleme zu lösen, besteht die Möglichkeit, Datenhaltungen in Clustern vorzunehmen, weiteres Memory zur Verfügung zu stellen oder mehrere CPU’s zu installieren. Alle diese Möglichkeiten, die dann beispielsweise auch ein performantes Online Backup ermöglichen, sind derzeit in SQLBase nicht vorhanden.

Um herauszufinden, ob und ggf. wo Engpässe vorliegen, führt MD Consulting ein Audit durch, dessen Auswertung Anhaltspunkte dafür bietet, wo z. B. die Indizierung verbessert werden kann und muss, bzw. wo und wie die Datenzugriffe aus den Anwendungen optimiert werden können.

So wurde eine Analyse der Geschäftsanwendung durchgeführt und die schriftliche schriftliche Fixierung der Ergebnisse bei gleichzeitiger Erarbeitung einer Vorgehensweise und von Empfehlungen für Verbesserungsmaßnahmen.

Die Analyse erfolgt mit folgenden Zielen:

1. Erarbeitung von Empfehlungen für mögliche Optimierungen der Geschäftsanwendung vor allem bezüglich der Datenbank Gupta SQLBase.

2. Erarbeitung einer Empfehlung für eine mögliche Migration auf ein alternatives Datenbanksystem (z.B. MS SQLServer oder Oracle) und der Erstellung eines Maßnahmenplans für eine Migration auf ein alternatives Datenbanksystem. Der Maßnahmenplan beinhaltet im Wesentlichen folgende Punkte: Vorgehensweise, notwendige Aufwendungen, Bedarf an Lizenzen, Bedarf an Schulungen.

Bestandsaufnahme Installation:
Maßnahmen und Empfehlungen:

• Installation SQL Console auf Datenbankserver
• Arbeit mit SQL Console
• SQL.INI
• Arbeit mit Views
• Arbeit mit Triggern und Stored Procedure

Team Developer:

• Einweisung Isolation Level , Demonstration Read Only Connect (mit Session Connect , um nur einen Handle im RO Level zu connecten)
• Fehlerbehandlung When SqlError
• Behandlung Bind Variablen in Where Clauseln (Empfehlung keine Bind Variablen)
• Empfehlung localer Sql Handle in Funktionen
• Keine umfangreiche SQL Aktionen (Insert,Update) in Fetch Schleifen
• (Daten in Arrays buffern

Analyse der Team Developer Anwendung:
Kleine Musteranwendung TD 6.2:

• Mit Connect Funktionen
• Bufferung SQL Ergebnisse in Arrays
• Funktionelle Klassen
• Table/Grid
• Connect auf Microsoft SQL Server (ODBC/OLE DB)
• Connection String (Erzeugen einer UDL Datei)

Fazit:
Empfehlung zum Umstieg auf Microsoft SQL Server gab MD Consulting vorerst nicht ab. Stattdessen wurde die Optimierung der Team Developer-Anwendung focusiert.

Beratung vor Ort
SQLBase-Anwendern, die entweder selbst keine Mitarbeiter mit dem benötigten Know-how haben oder aus anderen Gründen diese Aufgaben nicht selbst durchführen können oder wollen, bietet MD Consulting an, in einem Einsatz vor Ort sowohl den Zustand der Datenbank(en) zu ermitteln, als auch ggf. Verbesserungen direkt vorzunehmen oder Vorschläge zu unterbreiten, wie das jeweilige Datenbanksystem verbessert werden kann.

Konfiguration

Die SQLBase konfiguriert sich bei der Installation sozusagen selbst. Das bedeutet aber zunächst nur so viel, dass die SQLBase gestartet werden kann und ihre Arbeit fehlerfrei aufnimmt. Optimal auf die Ansprüche des Kunden oder die verfügbaren Ressourcen abgestimmt wird sie damit aber nur in den seltensten Fällen sein.

Administration

Zwar gilt die SQLBase als weitestgehend wartungsfrei, doch ist ein gewisses Mindestmaß an Administration unverzichtbar, wenn nicht nur das Datenbanksystem zuverlässig und performant seine Aufgaben erfüllen soll, sondern auch für Datensicherheit im Fall des Falles gesorgt sein muss. MD Consulting erhebt den aktuellen Zustand und gibt Empfehlungen für Verbesserungen im Leistungsverhalten und in der Datensicherheit.
Falls gewünscht und noch nicht geschehen, richtet MD Consulting die Datensicherung ein und schafft die Voraussetzungen für die Durchführung von Datenbank-Reorganisationen.

Software

MD Consulting zeigt die Stärken und Schwächen der von Ihnen eingesetzten SQLBase-Versionen auf gibt ggf. Empfehlungen für Upgrades.

Hardware

MD Consulting berät Sie, ob und – wenn ja – mit welchen Investitionen in die Hardware die Performance Ihrer SQLBase entscheidend erhöht werden kann.

Aufgabenstellung beim Kunden:

• die Migration der Team Developer Anwendung von 4.1 auf 6.2 und die Installation der Anwendung
• Upgrade der Datenbank auf Version 11.7, Installation und Einrichtungen der Dienste
• Umstellung TD Applikation Version 2005.1 auf TD 6.2
• (30 APP Files – je 1 Formular und 3-4 Dialoge)

Installation:

• Übergabe Datenträger SQLBase 11.7 und Team Developer 6.2
• Installation SQLBase 11.7 auf neuen Datenbankserver
• Installation der Team Developer 6.2 auf Client Rechner
• Test Datenbank Connect ok.

Migration:

• Vorbereitung in Version 2005.1
• Speichern der APP Files als Text Files *.APT
• Laden der * APT Files im TD 6.2
• Test der Applikation

Einweisung Neuerungen TD 6.2 (2. Tag)

• Arbeit mit Themes
• Neue Controls (NavBar, TreeControl)
• Grid (Testformular mit Grid / Gruppierung und Druck aus Grid)
• Erstellung einer MDI Applikation (Einbindung der 30 APP Files als Library) – testweise mit einem Formular