Hallo, David.
Ich debugge einfach anders.
Ich finde die PGDBE schlicht großartig. Okay, wer eine wirklich,
wirklich komplexe Anwendung hat, der hat
deutlich mehr Aufwand mit der Transformation, als das "few lines of code"-Werbeversprechen suggeriert, aber auch dieser Aufwand ist zu bewältigen, und wenn man nicht mit sehr großen Datenbanken hantiert, ist die ISAM-Emulation im Normalfall überall
deutlich schneller (und stabiler) als FOXCDX/DBFNTX (und die ADSDBE).
Unser größtes Problem war (teilweise ist es noch nicht ganz gelöst) die Mehrmandantenfähigkeit der Anwendung. Mit DBF und sogar im ADS lässt sich das mit simplen SET DEFAULT- und SET PATH-Kommandos steuern, und explizite Pfadangaben sind nur in bestimmten Servicesituationen nötig. Dadurch ließ sich eine gemeinsame und eine wechselnde Datenmenge elegant abbilden (Teil der Daten sind mandantenübergreifend, andere mandantenbezogen). In der PGDBE gibt es dafür kein Konzept, allerdings gibt es von/bei Alaska ein Strategiepapier dazu. Man kann das, kurz gesagt, über drei Wege abbilden, nämlich über Felder in allen Tabellen, die entsprechend gefiltert werden (sehr aufwendig und fehleranfällig), über Namespaces (unterstützt das Upsize-Tool leider nicht, wäre aber cool) oder über getrennte Datenbanken (bislang der Königsweg). Da es keine Kraft kostet, mehrere Connections zu haben, nutzen wir diesen Weg, aber diese elegante Einfachheit zweier Schalter, die alles andere erledigen, ist dadurch leider weg. Und wir brauchen je User immer zwei aktive Server-Verbindungen mindestens.
Wir werden Ende des Jahres dazu übergehen, auch alles andere, was wir im Moment noch in klassischen Ordnerstrukturen halten (Einstellungen, Dokumente, Bilder usw.) in die Datenbanken zu überführen. Und dann schauen wir mal, wie lange wir DBF und ADS und PG parallel supporten.