|
TurboDB Studio ist eine stark verbesserte und in vielen Bereichen gründlich überarbeitete Version von TurboDB Studio 3. Deshalb bleibt es nicht aus, dass einige Detail aus Ihrem VDP 3-Projekt geändert werden müssen, um mit TurboDB Studio fehlerfrei zu arbeiten. Die folgende Liste stellt eine kurze Übersicht über die notwendigen Änderungen dar, eine ausführliche Anleitung finden Sie im Abschnitt "VDP-Anwendungen für TurboDB Studio anpassen".
| • | TurboDB Studio kann nur die Projekt-Dateien von VDP 3 lesen. Projekte von VDP 2 und davor werden nicht mehr akzeptiert. Falls Sie ihr Projekt mit einer älteren Version erstellt haben, benutzen Sie den im Paket enthaltenen VDP 3 Standard, um das Projekt auf den aktuellen Stand zu bringen. Dazu öffnen Sie einfach das Projekt in VDP 3. Dann starten Sie den Formular-Editor für jedes Formular im Projekt und wählen den Menüpunkt Speichern. Nun können Sie das Projekt in VDP 3 wieder schließen und in TurboDB Studio öffnen. |
| • | VDP 3 und alle Vorgänger setzen auf Datentabellen das ReadOnly-Flag, wenn diese geschlossen werden. Die Idee dabei war, dass ein versehentliches Löschen nicht so einfach geschehen kann. Dieses Verfahren ist aus mehreren Gründen nicht mehr zeitgemäß. Zum einen zeigt Windows heute beim Löschen einer Datei selbst eine Sicherheitsabfrage an. Zweitens gibt es vielfältige Möglichkeiten des Zugriffsschutzes, mit denen Datensicherheit erreicht werden kann. Andererseits verhindert das ReadOnly-Flag auf einem Web-Server oft, dass man die Datei editieren oder löschen kann. Somit haben wir uns entschlossen, ab TurboDB Studio das ReadOnly-Flag genau zu dem zu verwenden, wozu es auch gedacht ist. Tabellen mit ReadOnly-Flag können zwar betrachtet aber nicht geändert werden. Wenn Sie ein altes Projekt mit TurboDB Studio öffnen, werden Sie deshalb gefragt, ob etwaige ReadOnly-Flags auf den Datenbank-Dateien entfernt werden sollen. |
| • | Bisher konnte man Memo-Feldern Zahlen zuweisen, z.B: |
MEINETABELLE.Bemerkung := 0;
Dies ist aber eine gefährliche Programmiertechnik. Mit obigem Aufruf entsteht z.B. ein "verwaistes" Memo in der Memo-Datei, welches außer bei Restrukturierung nicht mehr freigegeben werden kann. Deshalb sind solche Zuweisungen nicht mehr erlaubt. Erlaubt ist:
MEINETABELLE.Bemerkung := "";
| • | TurboDB Studio unterstützt nun erheblich besser als VDP 3 globale Variablen in Modulen. Alle Module des Projektes bleiben vom Übersetzen an komplett im Speicher, wodurch die globalen Variablen ihren Wert behalten, bis das Projekt geschlossen oder neu übersetzt wird. Eine Folge davon ist, dass globale Variablen in mehreren Modulen nicht den selben Namen haben dürfen. Sollten Sie globale Variablen mit dem gleichen Namen in mehreren Modulen des selben Projektes benutzen, müssen Sie sie entsprechend umbenennen. Beim Übersetzen weist Sie TurboDB Studio auf solche Variablen hin. |
| • | Die Objektorientiert Programmierung wurde in TurboDB Studio erweitert und ausgebaut. Eine Folge davon ist, dass bestimmte eigentlich falsche Konstrukte, die in VDP 3 noch akzeptiert wurden nun nicht mehr übersetzt werden. Z.B: |
vardef obj: Object;
obj := FindDataWnd('XXX');
obj.CloseWnd;
Da obj "nur" ein ganz normales Objekt ist und kein Datenfenster, kann es auch kein CloseWnd ausführen. In VDP 3 wurde diese Sequenz allerdings noch ausgeführt, in TurboDB Studio müssen Sie es richtig schreiben:
vardef obj: DataWnd;
obj := FindDataWnd('XXX');
obj.CloseWnd;
| • | Die Funktion ExecMacro ist durch das neue Programm-Konzept, bei dem alle Module immer geladen sind überflüssig geworden. Sie sollten Aufrufe wie |
ExecMacro(MeinModul, DieProzedur(8))
ersetzen durch
MeinModul.DieProzedur(8)
Diese Aufrufe sind nicht nur wesentlich weniger fehleranfällig sondern vor allem auch erheblich schneller, weil dabei nicht erneut ein Programm in den Speicher geladen werden muss. Die Funktion ExecMacro funktioniert allerdings weiterhin in den meisten Anwendungsfällen. Sie müssen nur darauf achten, dass das aufgerufene Modul im Projekt enthalten ist. ExecMacro-Aufrufe in Modulen werden teilweise nicht mehr übersetzt und sollten durch direkte Aufrufe ersetzt werden. (Siehe auch ExecMacro.)
| • | Wenn Sie Funktionen aus DLLs aufrufen, die Strings erwarten, müssen Sie entweder in der Deklaration ein as LPStr ergänzen oder nach aktuellem Windows-Standard die Version für Unicode-Strings benutzen. Bei den Standard-Windows-Funktionen ist das die Version mit W am Ende statt wie bisher mit A. |
| • | Doppelte Prozedurnamen innerhalb eines Moduls sowie solche, die einen Punkt im Namen enthalten, wurden bisher nicht als Fehler betrachtet. Ab TurboDB Studio schon. Außerdem war es bisher teilweise möglich, Prozeduren aus anderen Modulen zu verwenden, ohne diese mit Uses oder Include einzubinden. Jetzt erhalten Sie hier eine Fehlermeldung und müssen ein Uses ergänzen. |
| • | Wenn die Funktionen Exists, LinkSum und LinkCount auf die Primärtabelle angewendet wurden, haben sie keine Schleife über die Tabelle durchgeführt, sondern nur den aktuellen Datensatz berücksichtigt. Diese wurde erweitert, so dass man jetzt mit Exists, LinkSum und LinkCount auch über die Primärtabelle suchen, summieren und zählen kann. Für Link, LinkSum und LinkCount gibt es neue alternative Namen: LoopRecs, SumRecs, CountRecs. |
| • | Ausdrücke in Formelfeldern und Zeilen in Modulen und Datenbankjobs konnten schon bisher nicht mehr als 255 Zeichen umfassen. In VDP 3 und früher wurden solche Ausdrücke stillschweigend abgeschnitten. Jetzt wird eine Fehlermeldung angezeigt. |
| • | Die Funktion ReadLn hat bisher keinen Fehler gemeldet, wenn der Dateizeiger schon am Ende der Datei angelegt war. Jetzt kommt in diesem Fall wie auch bei Read ein Lesefehler. |
| • | In früheren Versionen konnte man hinter eine Zeile beliebige Kommentare schreiben, z.B. |
ReadRec(A, 1); Den ersten Datensatz lesen.
Hier muss jetzt wie auch sonst ein Kommentarzeichen stehen, also:
ReadRec(A, 1); ..Den ersten Datensatz lesen.
Dies gilt auch für vermeintliche Variableninitialisierung:
vardef a: Integer = 2;
Hier wurde das = 2 in VDP 3 als Kommentar betrachtet und deshalb nicht ausgeführt. TurboDB Studio meldet jetzt einen Fehler, damit die Situation klar ist.
| • | Die Abkürzungtaste Strg+F9 zum Ausführen eines Moduls oder Datenbankjobs wurde der einfacheren Bedienung wegen durch F9 ersetzt. Strg+F9 dient jetzt zum Übersetzen des ganzen Projekts. |
| • | Die folgende Befehlssequenz hat in VDP 3 dazu geführt, dass der neue Datensatz im Datenfenster editiert wurde: |
ReadRec(0)
WriteRec(FileSize+1)
EditRec
Das ist aber eigentlich nicht korrekt und dementsprechen, wird in TurboDB Studio jetzt der Datensatz editiert, der vor Aufruf dieser Sequenz im Datenfenster selektiert war. Wie sonst auch, braucht man auch in diesem Fall jetzt ein Attach, um den neuen Datensatz zu editieren:
ReadRec(0)
WriteRec(FileSize+1)
Attach
EditRec
| • | Der Datentyp TBits wurde aus Konsistenzgründen in Bit umbenannt. |
| • | Frühere Versionen von TurboDB ließe doppelte Spaltennamen in Tabellen zu, d.h. es war möglich zwei Spalten der selben Tabelle z.B. Name zu nennen. Das dies natürlich immer wieder zu Problemen führte (welches ist gemeint wenn auf Feld Name verwiesen wird?), prüft TurboDB Studio dies beim Öffnen einer Tabelle ab und zeigt ggf. eine Meldung an. Sie sollten im Sinne einer größeren Klarheit diese Felder umbenennen, z.B. in Name1 und Name2. |
| • | Da es die neue Systemvariable Project bzw. Projekt gibt, werden Spaltennamen einer Tabelle namens PROJEKT nicht mehr als solche erkannt. PROJEKT.Name führt zur Fehlermeldung "unbekannter Bezeichner: Name". Mit einem $ davor geht es wieder: $PROJEKT.Name. |
| • | Die Funktionen DateStr und DateTimeStr liefern jetzt für Werte kleiner als 367 die Jahreszahl 0: DateStr(1) -> 1.1.0000 |
| • | Die Funktion Choice/xWert benötigt eigentlich mindestens zwei Argumente. Falls nur ein Argument angegeben war, lieferte sie bisher einen zufälligen Wert zurück. Jetzt kommt beim Übersetzen ein Fehler. |
| • | Der Steuerbefehl HL hat das Argument in alten Versionen fälschlicherweise nicht in der mit MM eingestellten Maßeinheit interpretiert und deshalb war die Länge der Linie abhängig von der Auflösung des Druckers. Jetzt hat die Linienlänge die selbe Maßeinheit wie alle anderen Angaben im Datenbankjob. |
| • | Die Funktion GetStars erwartet als Parameter jetzt ein Integer-Array, statt bisher ein Real-Array. |
|