Bei unserem Kunden betreibt eine kleine zwei-Mann-Abteilung die IT. Neben den laufenden Wartungsarbeiten und der Anwenderunterstützung ist auch nebenher noch die Entwicklungsarbeit zu leisten.

Die Ausgangssituation war eine SQLBase 7.5 auf einem Server mit Novell 5.0 mit fünf Datenbanken zu den verschiedenen Anwendungsbereichen. Die Anwendungen wurden mit Team Developer 1.5.1 entwickelt und von den Anwendern über einen CITRIX Server auf Windows 2008 bedient. Zusätzlich existiert noch eine zugekaufte Gupta-Anwendung (unter Team Developer 2.0 entwickelt) zu der kein Quellcode zur Verfügung steht.
Vorgesehen war die Migration der Anwendungen auf Team Developer 6.1 und die Migration der Datenbanken auf SQLBase 11.7.

Zuerst wurde die SQLBase auf einem neuen Windows 2008 R2 Server installiert und mit EMP 5502 modifiziert. Das Laden der „Unloaddateien“ verlief bis auf die Datenbank der zugekauften Anwendung problemlos. Ausgerechnet die „Quellcodelose“-Anwendung verwendete bei einer Tabelle den Spaltennamen „RIGHT“, der bei der neuen Datenbankversion nicht mehr erlaubt ist. Nach dem Umbenennen der Spalte konnte die Datenbank dann geladen werden. Da die entsprechende Tabelle nur vier, bei der Urprogramminstallation angelegte Einträge enthielt, kann man davon ausgehen, dass die betroffene Tabelle wohl auch in Zukunft durch das Programm nicht angesprochen wird.

Anschließend wurde der Team Developer 6.1 auf einem Windows7 64 Bit System installiert und die Anwendungen nachdem sie ins Textformat konvertiert wurden, migriert. Die „Unloaddateien“ der DBs wurden dann auch auf dem Entwicklungsrechner auf der lokalen SQLBase installiert. Nach einem kurzen Testbetrieb der problemlos migrierten Anwendungen wurden dann die entsprechenden Exen erzeugt, um diese auch in der produktiven Umgebung (Windows 2008 CITRIX) zu testen.

Die Laufzeitumgebung hierzu wurde dann auf dem Entwicklungssystem generiert. Man erhoffte sich davon eine Kopiervorlage um die Umgebung per Skript erstellen zu können. Doch ein Versuch die Anwendungen mit der kopierten Runtime zu starten, schlug fehl. Erst ein Erzeugen der Laufzeitumgebung auf dem Server brachte den gewünschten Erfolg. Allerdings war schnell klar, dass die Performance des migrierten Systems ein Beobachten des Maskenaufbaus zuließ und deshalb vollkommen unzureichend war.
Erst die Installation von Team Developer 6.1 SP3R, die zufällig einen Tag später von Gupta freigegeben wurde, ließ die Anwendungen wieder mit der gewohnten Geschwindigkeit arbeiten.

Client-/Server-Projekt

Consulting
1 Manntag

Technologie:
GUPTA Team Developer 6.1
SQLBase 11.7

18. Januar 2017

Unser Kunde entwickelt Bibliothekssoftware, welche aus verschiedenen Programmen und Schnittstellen besteht. Darunter befinden sich einige Anwendungen, erstellt Mitte der 90er Jahre, die bis heute ihre Daseinsberechtigung hielten und mittlerweile mit dem Team Developer 4.2 weiter entwickelt – durch häufigen Wechsel der Programmierer eher angestückelt als gepflegt – werden.

Der Source und die Anwendung sollen weiterhin auf der Win32-Basis belassen werden, da der Einsatz von ActiveX und einigen externen Schnittstellen via DLL-Einbindung zu viel Aufwand bei der Umstellung nach .NET bedeuten würde. Da es neben der Team Developer-Abteilung auch eine .NET-Abteilung gibt, wollte man durch den Einsatz des Team Developer 6.x erreichen, Schnittstellen und eine entsprechende Codebasis gemeinsam nutzen zu können. Daher das Vorhaben, die bestehenden Team Developer-Anwendungen auf die Team Developer Version 6.x zu migrieren, um den gestiegenen Anforderungen gerecht zu werden.
Migrationsverlauf:

• Erläuterung und Abstimmung der Migrationsschritte.
• Migration der Hauptanwendung von der Team Developer Version 4.2 nach Team Developer 6.0 Service Pack 5.

Die relativ rasche Umstellung der ActiveX-Komponenten und der Unicode-Anpassungen brachte einen schnellen Erfolg der Migration. Die teilweise durchgeführten Tests zeigten keine schwerwiegenden Probleme auf. Ein ausführlicher Test ist allerdings notwendig und geplant, da auch einige Schnittstellen zu externen Systemen geändert wurden.

Nun erfolgte die Vorstellung der neuen Features des Team Developer 6.x., sowie die Einweisung der Kundenmitarbeiter in die Konsumierung von .NET-Funktionalität.
Bei der Demonstration war ein sehr positives Feedback zu erkennen, da dies doch recht einfach zu handhaben ist. Zusammen mit der .NET-Abteilung wurden diverse Tests erstellt, um aufzuzeigen wie die Funktionalitäten eines intern erstellten Assemblys mit dem Team Developer verwendet werden könnte.

Als weitere gemeinsam verwendbare Schnittstelle wurde die Bereitstellung von Webservices erläutert. Demonstriert wurde dies anhand eines klassischen Webservices (ASMX – Webservice)  und der Konsumierung mit dem Team Developer 6.0 und dem Team Developer 6.1.

Da die intern erstellten Webdienste allerdings mittels WCF (Windows Communication Foundation) und dem Framework 4.0 erstellt wurden und werden, bestand die Anforderung, ebenfalls diese konsumieren zu können. Da hier Restriktionen Seitens des Team Developer bestehen und beachtet werden wollen, konnten wir durch unsere Erfahrungen dem Kunden viel Forschungsarbeit ersparen.

Fazit:

• Umstellung der Anwendung vom Team Developer 4.2 auf den Team Developer 6.0 verlief schnell und problemlos
• Anforderung der Konsumierung von .NET-Funktionalität mit dem Team Developer unter Beachtung vorhandener Einschränkungen umsetzbar
• Einsatz von klassischen Webservices möglich
• Erste Schritte der Konsumierung von WCF-Webdiensten sind gemacht, weitere Details sind zu untersuchen

Client-/Server-Projekt

Consulting
2 Manntage

Softwareentwicklung

Technologie:
GUPTA Team Developer .NET
WCF
Framework 4.0

18. Januar 2017

Unser Kunde hat eine Gupta Team Developer Applikation für die Holz- und Möbelindustrie.
Seine unterschiedlichen Applikationen sind am Puls der Zeit, da sie permanent angepasst und weiterentwickelt werden.
Der Anspruch immer „up to date“ zu sein, birgt das Risiko, auf „Kinderkrankheiten“ der Betriebssysteme, Datenbanken und Entwicklungswerkzeuge zu stoßen. So wurde MD Consulting gerufen.
Ziel war es, die Anwendung zu den bestehenden Problemen der SQLBase 11.7 mit Timeouts und Deadlocks, insbesonders bei 64bit (Win7 und Win8) zu analysieren und Lösungsansätze zu eruieren.

Die Vorgehensweise waren zuerst die Analyse der SQLBase Konfiguration und die Analyse von Programmcode, der für die Deadlocks in Frage kommt.
Nach der Analyse konnten durch Anpassungen in der sql.ini und im Programmcode die richtigen Werte für InMessage-Buffer, OutMessage-Buffer und Isolation-Level gefunden werden. Gleichzeitig konnten an mehreren Programmstellen Blockademöglichkeiten durch Cursor-Commits entfernt werden.

Viele Probleme konnten erfolgreich gelöst werden. Einige Nacharbeiten mussten wir mit nach Hause nehmen. So konnten wir etwas später eine erweiterte Definition der Tracing-Dateien unter SQLBase nachliefern.

PS: Zu einem späteren Zeitpunkt trat bei einem anderen Endkunden ein ganz anderes gelagertes Problem mit der SQLBase auf. 80 User konnten nicht arbeiten bzw. flogen alle 2-3 Stunden mit Ihrer Applikation raus. Da sprang wegen Urlaubszeit bei MD Consulting der Hersteller höchst persönlich ein. Mike Vandine wurde in Australien geweckt, ini´s gingen rund um den Globus und in kürzester Zeit war das Problem behoben.
Ein Dank an Mike Vandine von Gupta Technologies von MD Consulting.
Auch der Kunde bedankte sich: “… at the moment the system works fine and everybody is happy. We had NO crash today. About 20 concurrent users working on the database.”

Client-/Server-Projekt

Consulting
2 Manntage

Softwareentwicklung

Technologie:
GUPTA SQLBase 11.7

18. Januar 2017

Ein Schwein ist krank oder ein Kalb will nicht selbstständig auf die Welt kommen. Probleme, die schnellst möglichst vor Ort gelöst werden müssen. Tierärzte im Einsatz: Kaum ein Einsatz abgeschlossen ruft schon wieder der Nächste. Alle Daten müssen vor Ort auf der Weide oder im Stall abrufbar sein und natürlich müssen alle Einsätze abgerechnet werden. Damit nichts vergessen wird, am besten sofort.

Das Abrechnungsprogramm, eine Gupta Team Developer Lösung, sollte nun auf die neuen SEPA-Lastschriften umgestellt werden.
Im ersten Teil des Coachings vermittelte der Kunde die Funktionsweise der XMLLIB.APL.
Dann erstellten wir nach Vorlage der Sparkasse die nötigen Bausteine zur Erstellung der SEPA-XML-Datei.
Zum Abschluss wurde die Datei durch das Prüfprogramm der Sparkasse verifiziert und für gut befunden.
Der Kunde war mit dem Ergebnis des Coachings sehr zufrieden.

Client-/Server-Projekt

Softwareentwicklung
1 Manntag

Technologie:
GUPTA Team Developer

18. Januar 2017

Eine bestehende Anwendung für das Tracking von Strafmandaten und eine entsprechende Kassensoftware, erstellt mit dem TD 3.1, soll lt. Kundenanforderung ins Web umgestellt werden. Hierbei sollten verschiedene Wege vorgestellt und betrachtet werden.
Die Anwendung enthält zahlreiche DLL-Aufrufe und ActiveX-Komponenten. Die Umstellung nach TD 5.2 wurde durch den Kunden bereits realisiert.

Inhalt des Workshops:

• Grundlagen zur Migration nach TD 6.x Win32
• Grundlagen zur Migration nach TD 6.x .NET
• Grundlagen XAML – Verwendung von WPF-Controls
• Konsumieren von .NET-Assemblies
• Gegenüberstellung einer Web-Anwendung und einer browserbasierten Anwendung
• Aufgrund der bestehenden Programmstruktur wäre die Umstellung auf eine Web-Anwendung zu aufwändig
• Erstellen und Einrichten einer XBAP-Anwendung
• Erstellen einer Liste von erforderlichen Eckdaten zur Klärung mit dem Endkunden

Folgende Probleme sind bei der Migration aufgetreten:

• Datenbankzugriff auf SQL Server über ODBC
• DB-Connect unter .NET funktionierte nicht, unter Win32 war es ok;
  OLEDB funktionierte, konnte aber nicht mit Subselects umgehen
• Umstellung auf TD 6.1 .NET durchgeführt – DB Connect erfolgreich
• Durch die Projektstruktur der umzustellenden Software war eine Migration direkt nach TD 6.1 Win32 nicht möglich, da der Compiler nicht alle enthaltenen DLL-Aufrufe umsetzen konnte. Deshalb erfolgte die Migration nach TD 6.0 Win32 und die Anwendung wurde soweit abgespeckt, dass nur die notwendigen Module enthalten waren. Test unter TD 6.0 Win32 erfolgreich
• Die DLL-Aufrufe wurden in ein .NET-Assembly gepackt, welches eingebunden wurde
• Probleme traten auf, wenn Member-Variablen einer Klasse als Bindvariablen verwendet wurden. Das Select-Statement wurde hier nicht korrekt ausgeführt.

Lösung brachte hier die Umstellung der Statements ohne Bindvariablen. Im TreeView-Control wird bei Verwendung der Funktion SalTreeSetSelectedItem zwar das Item selektiert, aber nicht in den sichtbaren Bereich bescrollt. Dies ist allerdings nur bei der Eigenschaft ShowRoot = NO falsch. Ist diese Eigenschaft auf Yes gesetzt, ist das Scroll-Verhalten richtig

Eine Liste von notwendigen Voraussetzungen konnte erstellt werden. Der Kunde kennt nun die Schritte zur Umstellung seiner Anwendung als XBAP-Anwendung. Bei Umstellung der Anwendung ist weitere Unterstützung vorgesehen.

Client-/Server-Projekt

Softwareentwicklung
2 Manntage

Technologie:
GUPTA Team Developer

18. Januar 2017

Bisher wurden verschiedene Anwendungen über Citrix den Anwendern in verschiedenen Kantonen zur Verfügung gestellt. Da dies mit erheblichen Aufwand und auch Kosten bei der Bereitstellung des Citrix-Clients verbunden ist, möchte man dies durch Bereitstellung einer Browseranwendung einsparen.

Migrationsverlauf:

• Vermittelt wurden Grundkenntnisse für die Verwendung von WPF-Controls. In einem bestehenden Projekt wurde dies bereits anhand der ProgressBar praktiziert. XAML wurde hier aufgrund der Gesamtzeit des Workshops vernachlässigt.
• Vermittelt wurde die Vorgehensweise beim Ersetzen von WinAPI-Funktionen durch äquivalente .NET-Funktionalität. Dabei wurden Grundkenntnisse beim Konsumieren von .NET Assemblies vermittelt und anhand der WinAPI-Funktion ShelExecute praktisch umgesetzt.
• Vermittelt wurde die Erstellung von WPF-Browser-Anwendungen. Hierbei wurde speziell auf das Veröffentlichen dieser eingegangen. Speziell auf die Erstellung eigener Zertifikate und Anpassung der index.htm zur Bereitstellung einer individuellen Installationsanleitung.
• Diskussion zur Verwendung von Web Services sowie Demonstration zum Erstellen und Konsumieren von Web Services.
• Verwendung der MS Office Interop

Folgende Probleme sind bei der Umstellung nach .NET aufgetreten:

• Menü wird nicht korrekt übersetzt – Funktion VisMenuGetText funktioniert unter .NET anders als unter Win32, dieser Bug wurde an GUPTA gemeldet.
• Im Menü sind unter .NET keine Mnemonics sichtbar.
• Der Background verschiedener Controls ist nicht transparent, daher unschöne Anzeige der GUI.
• VisTblSetCellColor wird unter .NET nicht unterstützt – gibt es ein Äquivalent?
• SalGetFileStr liefert unter .NET nicht nur die erste Zeile wie unter Win32, sondern die ganze Daten zurück.
• Variablenreferenzierung bringt Fehler (ist allerdings zum Teil bedingt durch den Aufbau der Programmstruktur) Workaround oder Beseitigung der Fehlermeldung wurde erarbeitet.
• Keine HTML-Hilfe unter .NET.
• Remote Publishen einer WPF-Browser Anwendung funktionierte nicht – Alternative über locales Publishen und Kopieren auf dem Remote-Rechner.

Hierzu werden teils Testfälle durch den Kunden erstellt, damit die Fehler im Rahmen des Migrationstages an Gupta gemeldet werden können. MD Consulting konnte 2 EMPs für den Kunden bewirken.
Für nicht mehr unterstützte Funktionalitäten wird nach äquivalenten Möglichkeiten gesucht und der Kunde darüber informiert.
Für einen Tag sehr viel geschafft!

Client-/Server-Projekt

Softwareentwicklung
1 Manntag

Technologie:
GUPTA Team Developer .NET

18. Januar 2017

Die eingesetzte Softwarelösung wurde Ende der 90er Jahre entwickelt und ist seitdem im Einsatz. Diese Anwendung wurde zuletzt mit dem Team Developer 2.1 entwickelt und nutzte eine SQLBase 7.6.1. Aktuell ist das Programm auf Team Developer 6.1 migriert und nutzt eine SQLBase 9.0.1.
Im Moment werden die Betriebssysteme WinXP SP3 und Windows7 32 Bit eingesetzt.
Im Multi-User-Betrieb von ca. 15 Anwendern kommt es sporadisch zu Programmabstürzen, was bereits unter der TD 2.1 Version vorkam. Weiterhin entstehen oft längere Wartezeiten beim Datenbankzugriff.
Das Audit der SQLBase Datenbankzugriffe soll protokolliert und ausgewertet werden.

Inhalt des Workshops:

Erstellen und Auswertung eines Audit der verwendeten Datenbank SQLBase 9.0.1.
Untersucht wurde die produktive Datenbank. Die anderen verwendeten Datenbanken spielen bei den auftretenden Problemen eine untergeordnete Rolle und wurden nicht näher analysiert.
Über die SQLConsole 11.7 wurden folgende Audits protokolliert:
Global:

• Deadlocks / Timeouts
• Queries
• DML

Performance:

• SQL-Statements
• End of Transaktion

Weiterhin wurde die Datenbankstruktur analysiert unter folgenden Gesichtspunkten:

• Größe der DB
• Anzahl der Tabellen und Struktur
• Anzahl von Datensätzen
• Zusammen mit der Entwicklungsfirma der Software erfolgte eine Analyse des Programm-Sourcecodes und deren Auswertung:
  Hierbei wurde zusammen mit dem Entwickler auf Besonderheiten der Multi-User-Zugriffe eingegangen. Im Weiteren wurden bedenkliche Stellen im Source diskutiert und Verbesserungen vorgeschlagen.
• Diskussion über Möglichkeiten, die Software mit dem Team Developer nach .NET umzustellen:
  Hierbei wurde die komplette Umstellung des Programmes diskutiert, aber auch die sanfte Umstellung in Betracht gezogen.

Client-/Server-Projekt

Softwareentwicklung
2 Manntage

Technologie:
GUPTA Team Developer 6.1
GUPTA SQLBase 9.0.1

18. Januar 2017