Inoffizielles deutsches Xbase-Forum

das macht er auch, Du musst nur in den Tabelleneigenschaften das autocreate ankreuzen.

aha,
also erstmal selbst hand anlegen. Wenn man also eine neue DBF hinzufügt, dann muß man danach erstmal per Hand den parameter setzen!? Und ab da geht alles mehr oder weniger wie von selbst?

ja

einen SQL Befehl für sowas gibt es nicht?

ooops,
in dem Zusammenhang ist mir jetzt aber was ganz komisches passiert. Es existierte keine Indexdatei für die DBF. Die hatte ich händisch gelöscht. Wenn ich nun aus einem Programm heraus einen SQL Befehl abgesetzt habe, dann lieferte oSqlStmt:execute() NIL zurück. Habe ich aber den gleichen SQL Befehl über den Architekten im SQL Utility abgesezt, wurde mir das erwartet Ergebnis zurückgeliefert. Kann mir das jemand erklären, warum das so ist?

doch.











Ach so, Du willst auch noch, dass ich es aus der Hilfe heraussuche;)
Mache das bei einer Tabelle, dann rechte Maustaste - Create SQL (o.ä.) - dann die Stelle mit sp_SetTableProperty ... 'auocreate' suchen und kopieren.

Joachim,
sorry aber die Bissigkeit war jetzt nicht erforderlich. Du hast falsch geantwortet.
ich wundere mich das bei einer DBF zu der normalerweise ein index gehört, der aber gelöscht wurde aber auch kein Autocreate aktiv ist, aus einem Xbase++ Programm NIL geliefert wird als Ergebnis, aber im ARC ein Ergebnis kommt.

sorry,
Du hast auf weiter davor geantwortet. Gut, alles in Ordnung.
wobei das trotzdem nicht das war, was ich meinte. Für die Erzeugung ist mir das klar, aber wenn ich die Tabelle schon habe. Gibt es dafür einen SQL Befehl das nachträglich zu stellen?

Das Script machts für alle Tabellen

Hallo Manfred,

ein DataDictionary (DD) ist nichts anderes als auch eine besondere Tabelle. Ich meine, da stehen alle möglichen internen Tabellen drin. Z.B. welche Tabellen zum DD gehören, welche Indizes, welche User, Usergruppen, Stored Procedures, Functions, Views, RI Objects etc.

Z.B. mit oder kannst Du Dir alle Tabellen bzw. Indextabellen anschauen, die im DD enthalten sind.

Du kannst in der Hilfe auch nach

system tables

suchen. Vielleicht hilft das ein bisschen, um zu verstehen, warum der Server weiss, welche Indextabellen benötigt werden.

Edit: Markus hat in seinem Script auch die Tabelle System.Tables benutzt, um automatisch alle zum DD gehörenden Tabellen durchzugehen.

Wenn du ganz cool sein willst, benennst du die ADD nach adt und die ai nach adi, die am nach ADM dann kannst du die normal im ARC öffnen.

der Tipp mit system.tables ist gut.

@Marcus,
ist das jetzt ein Script das im Architekten laufen kann, oder wie muß ich das verstehen? Ich bin erst vor ein paar Wochen in SQL eingestiegen und etwas später erst in den ADS. Deshalb meine große Unkenntnis und Fragerei hier. Ich habe noch keine Ahnung was alles machbar ist und weiß auch deshalb nicht wonach ich suchen sollte.

Das ist ein Script, das du im ARC ausführen kannst. Dann setzt er in jeder Tabelle das Flag AUTOCREATE.
Ähnlich kann man jede andere Eigenschaft setzen. Es gibt immer ein zugehörige Procedure oder ähnliches, die man aufrufen kann.
Die doppelten einfachen Hochkommata sind für das Erzeugen eines Strings, der dann ausgeführt wird -> execute immediate. Ähnlich wie ein Macro in Xbase.

jetzt wird da langsam ein Schuh draus. Das Kennzeichen für Auto_Create ist gesetzt. Wenn das Backup gemacht wurde mit dem FLAG und wieder Restored wird, werden vorher die Indexdateien (händisch) gelöscht. Dann wird restored und im selben Rutsch werden die Indexdateien neu aufgebaut. Das ist ja echt Klasse. Oder müssen die vorher nicht gelöscht werden und der RESTORE Prozess baut trotzdem die Indexdateien automatisch immer neu auf?

jetzt wäre natürlich noch was interessant. In der DD Bank stehe die Infos für die Tabellen drin. Kann man denn .add und .am einfach in ein anderes Backup übernehmen um so die Parameter zu haben, wenn sich sonst nichts an dem DD geändert hat? Um ältere Backups auch mit dem auto_create z.B. nachzurüsten?

nein, würde ich nicht. Kann zu Unstimmigkeiten kommen, falls die Struktur nicht zu den Tabellen passt.
Für das Restore brauchst Du das Flag nicht. Das ist nur notwendig, wenn Du eine Tabelle öffnest und eine zugehörige Datei (DBF, CDX) ist nicht vorhanden. Dann legt der ADS Dir diese an.

ok, das sollte ja nicht der Fall sein. Es war ja die Frage, wenn sich nichts geändert hat.
Zu dem Index: wann gilt denn eine DBF als geöffnet? Schon wenn der Architekt die Tables anzeigt? Dann wäre es zu erklären, warum die Indexdateien alle sofort da waren, ohne das ich selbst was gemacht habe.
Aber es geht auch nicht um das Restoren so gesehen. Wenn restored wird, dann wird doch die ADD und Am Datei mit zurückgesichert und da steht doch dann alles drin, was zu den Tabellen gehört. Also auch das Flag für auto_create. Wenn ich nun ein viel älteres Backup zurückholen möchte um damit zu "spielen" und dort das Flag noch fehlt, dann genügt es doch nicht das Flag nachträglich zu setzen und schon ist alles gut!? Oder werden dan die Infos aus system.indexes geholt und dann die Indexdateien neu erstellt? Wäre natürlich auch eine Möglichkeit.

Das Restore erstellt die Indexe anhand der Definition in der ADD - auch ohne autocreate gesetzt.

das muß ich mal testen. Bei mir hat das nicht geklappt. Dann habe ich wohl irgendwas falsch gemacht.

jetzt stellt sich eine neue Frage. Ich habe Views erstellt. Werden die und die Procedures usw. eigentlich automatisch mitgesichert beim Backup, oder wie muß man da vorgehen?

Views und alles andere Proceduren, Trigger, etc. stehen in der ADD, die ja mitgesichert wird. Muss man sich nicht drum kümmern