Inoffizielles deutsches Xbase-Forum

Ich habe gerade mal ein Programm das bisher auf DBF Dateien im ADS zugegriffen hat versucht auf ADT Tabellen zugreifen zu lassen. Das ging natürlich nur bedingt auf Anhieb. Aber wo mache ich wohl einen Denkfehler?
Ich habe ein ADD angelegt mit reinen ADT Tabellen und dann mit dem Programm darauf zugegriffen. Das Öffnen einer ADT ohne Index klappt mit DbUseArea() Aber sobald ein Index im Spiel ist, knallt es mit dem Fehler 8999 beim Öffnen direkt.
Vorher hatte ich versucht über das Programm einen Index aufzubauen, das gab aber auch Fehler.
Error 3015 Invalid field type found in index key.

Für mich nicht nachvollziehbar.

Dann habe ich direkt im Architekten den Index erzeugt und dann knallte es mit 8999 beim Öffnen.
Kann man nicht so einfach statt DBF Tabellen ADT Tabellen nehmen? Was ist zu beachten wenn man auf reinen ADT umsteigen möchte?

Wie sieht denn Dein Index-Key aus ?

Str(id,8,0)

so sieht der aber auch in den DBF aus, die in einem anderen DD liegen

Wenn Du weiterhin mit der ADSDBE arbeiten möchtest, würde ich nicht ADT-Tabellen benutzen. Dazu ist die ADSDBE viel zu fehleranfällig.
Bei ADT-Tabellen würde ich keine Ausdrücke in Indizes mehr verwenden, sondern nur noch Feldbezeichnungen, z.B. Id oder Nachname;Vorname .
Damit laufen die Optimierungen bei SQL-Ausdrücken am Besten.

Uli

fehleranfällig? Bist Du sicher? Das wäre aber übel, weil ich vorerst die Funktionen von Xbase++ nutzen möchte/muß.

Manfred hat geschrieben:fehleranfällig? Bist Du sicher? Das wäre aber übel, weil ich vorerst die Funktionen von Xbase++ nutzen möchte/muß.

Du meinst DbUseArea()-Befehle etc.?
Dann würde ich auf DBF-Tabellen mit CDX-Indizes verwenden und zwar so, dass der ADS ausschließlich auf die DBF-Tabellen zugreift und zugreifen darf.

Uli

so ist es ja derzeit. Die Idee geht aber dahin auf ADT zu stellen. Ich teste es aber auch nur gerade um zu schauen, ob es wirklich machbar ist.

und was muß jetzt genau gemacht/beachtet werden, wenn man von DBF auf ADT wechseln will?

Das Wichtigste:
Die ADSDBE nicht verwenden. Wenn Du die doch verwenden möchtest, auf ADT verzichten.

Gegenfrage: warum willst Du auf ADT-Tabellen umsteigen?

weil ich mir denke, dass ich dann alle Features des ADS nutzen kann. Bisher nutze ich nur DBF /CDX im DD. Dort muß ich ja ein Pack machen z.B.
Ich hatte mal kurz in Postgres reingeschnuppert (muß aber noch zu viel anpassen deshalb gehe ich den Zwischenweg für eine Zeit, bis die Programme alle auf SQL umgestellt sind) und da hat mich absolut fasziniert, das man während des Betriebs alle Änderungen an der Datenbank machen kann, ohne den Betrieb zu stören. Ich denk mal, das geht mit dem ADS und DBF nicht, aber mit ADT!?

Hi

Mit ADS 12 gibt es ONLINE CREATE INDEX und ALTER TABLE. Das ist in etwa dasselbe.
PostgreSQL kann das, weil ja jeder Nutzer, bzw. Abfrage eine Kopie der Daten hat.
ADS arbeitet mir Satzzeiger, da geht das eben nicht.

Schau dir doch auch mal AdsClass an. Nur dass du zwischen mehreren Möglichkeiten dich entscheiden kannst.
Bei Umstieg auf ADT gibt es ein paar Dinge zu beachten,
-NULL Werte zum Beispiel.
-Evtl. auch andere/neue Indices, um SQL zu optimieren.
Index wie STR(KNDR)+STR(NR) kann von SQL nicht verwendet werden,
SQL will einen Index wie KDNR;NR ohne CAST und PLUS Zeichen, aber mit ; dazwiscchen, das kann meines WIssens die ADSDBE nicht.

Marcus Herz hat geschrieben: ↑Sa, 23. Mai 2020 13:19...
Bei Umstieg auf ADT gibt es ein paar Dinge zu beachten,
-NULL Werte zum Beispiel.
-Evtl. auch andere/neue Indices, um SQL zu optimieren.
Index wie STR(KNDR)+STR(NR) kann von SQL nicht verwendet werden,
SQL will einen Index wie KDNR;NR ohne CAST und PLUS Zeichen, aber mit ; dazwiscchen, das kann meines WIssens die ADSDBE nicht.

Weitere wichtige Punkte:
- Die Datensatz-Nr beim Anlegen von neuen Datensätzen wird nicht unbedingt aufsteigend vergeben
- Gelöschte Datensätze kann man nicht wieder zurückholen
- Speicherplatz von gelöschten Datensätzen wird recycled
- In logischen Ausdrücken sind die NULL-Werte immer wieder Stolperfallen: z.B. "Id>10 .or. Id<11" ergibt nicht grundsätzlich TRUE (bei Id=NULL kommt NULL heraus)
...

gestern ist mir noch was aufgefallen. Ich habe per INSERT einen neuen Datensatz angefügt in eine DBF und mußte feststellen, das es gar nicht so einfach geht. Es befinden sich nämlich logische Felder darin. Wenn man die aber nicht explizit angibt, schreibt der ADS da aber nicht FALSE rein, (DBF wird ja mit .F. belegt ) sondern gar nichts und das führt dazu, das es knallt, wenn man den Satz wieder aufruft. Mit dem Hinweis interne Struktur beschädigt. Wenn man aber jetzt alle felder mit einem Defaultwert belegen muß bei der INSERT Angabe, dann finde ich das schon wieder zu viel Arbeit, wenn es nicht gerade um 2 Felder geht.
Deshalb auch meine Frage in dem Trigger Thread, ob Du weitergekommen bist. Weil ich überlege, ob man sowas über den ADS vorgeben kann. Ebenso wie das Hochzählen einer ID

Hi
Wenn du Trigger hast, verwendest du ja ein Dic. Da kannst du Defaultwerte für jedes Feld definieren. Dann kannst du alle NULL Werte umgehen.

Manfred hat geschrieben: ↑Di, 26. Mai 2020 14:28 gestern ist mir noch was aufgefallen. Ich habe per INSERT einen neuen Datensatz angefügt in eine DBF und mußte feststellen, das es gar nicht so einfach geht. Es befinden sich nämlich logische Felder darin. Wenn man die aber nicht explizit angibt, schreibt der ADS da aber nicht FALSE rein, (DBF wird ja mit .F. belegt ) ...

Soweit ich weiss, wird auch von xBase bei DBFs nicht zwingend mit einem .F. vorbelegt. Ich meine, der NULL-Wert wird nur wie ein .F. behandelt.

Manfred hat geschrieben: ↑Di, 26. Mai 2020 14:28 ... sondern gar nichts und das führt dazu, das es knallt, wenn man den Satz wieder aufruft. ...

Habe ich nie erlebt. Vermutlich gibt es ein anderes Problem.

Ansonsten ist der Lösungsvorschlag von Marcus dafür viel eleganter als es mit einem Trigger zu lösen .

ich habe es direkt im Architekten gesehen. Und nachdem ich da false eingetragen habe von Hand, war das Thema durch. Bzw. nachdem ich FALSE als Vorgabe mit in den INSERT Befehl gepackt hatte. Also dürfte es das gewesen sein.

Ich vermute, Du irrst Dich. Ich kann mir beim besten Willen nicht vorstellen, dass der ADS die DBF zerstört und ein erneutes Aufrufen mit "interne Struktur beschädigt" quittiert.

Uli,
davon war überhaupt nicht die Rede. Ich sagte nur, das er nicht pauschal false einträgt. Und jetzt kommt der Punkt. Das Xbase++ Programm behauptet dann die DBF wäre kaputt. Ich hoffe das war jetzt genauer ausgedrückt als vorhin.

Danke für die genauere Erklärung.
Ich vermute, Du greifst mit dem xBase++-Programm auf die DBF mittels des ADSDBE-Treibers zu (direkt geht ja bei einem DataDictionary (*.add) ja gar nicht. Dann scheint mir der ADSDBE-Treiber defekt zu sein.

hm, das ist der aktuelle zur Xbase++ Version. Könntest Du mal sowas probieren, ob das bei Dir auch so einen Effekt gibt?

Soweit ich weiß, liefert Alaska immer noch die Clients der Version 8 aus. Auf jedenfall neuere Versionen nehmen.
Ich hab mir einen Batch geschrieben, welcher nach jedem Xbase Update diese löscht. Wenn die dann im Pfad ganz vorne stehen und eine App diese verwendet, sind neuere ADTs nicht zu lesen.