prüfen ob DBF existiert

[Manfred]

Im normalen Xbase++ Umfeld kann man das ja mit File() prüfen, ob eine DBf existiert. Aber wie löst man sowas elegant unter ADS? Wenn ich mit DbUsearea() versuche eine DBF zu öffnen, die nicht da ist, dann gibt es einen 8999 zurück. Den gibt es aber auch bei anderen Probleme zurück, könnte also Verwirrung stiften.

[Tom]

Hallo, Manfred.

Vielleicht sollte man parallel mal einen Thread eröffnen, in dem allgemein diskutiert wird, warum und wozu man den ADD verwenden sollte.

Der ADS stellt ja in der einfachsten Migrationsstufe nichts weiter als eine Instanz zwischen Deiner Anwendung und der Datenbankschicht dar, von der Du nichts (mehr) bemerkst, nachdem Du die Verbindung etabliert hast. Der Umgang mit Tabellen ändert sich bezogen auf die Programmlogik eigentlich nicht. Ob Du File() oder FExists() verwendest oder das DbUseArea() in eine Sequenz kapselst, um abzufangen, ob eine Tabelle existiert und verwendet werden kann, bleibt sich gleich. Anders wird das nur, wenn Du dem ADS eigene Rechte gibst und/oder den ADD verwendest, weil sich dann bestimmte Low-Level-Operationen verbieten, da sie in diesem Umfeld wirkungslos sind oder andere Wirkungen haben als bei purem DBFNTX/DBFCDX/Wasauchimmer.

Die Advantage Client Engine (ACE) bietet einen Satz an Funktionen (Download der Doku hier: http://devzone.advantagedatabase.com/Co ... ProjID=144 ), darunter auch solche, die die Existenz von Tabellen auf dieser Ebene prüfen lassen. Einige dieser Funktionen sind in der ADSDBE gewrappt, andere nicht - da müsstest Du das selbst nachholen.

So lange aber nicht besonders originell gearbeitet wird und Du weißt, wo sich die Tabellen befinden müssten, sollte tatsächlich File() (mit Suchpfad usw.) oder FExists() (ohne) genügen, um die Existenz einer Tabelle zu bestimmen.

[Manfred]

Hi Tom,

wie schon woanders und von Jan erwähnt, DD ist Vorschrift und dann klappen die Low Level Funktionen nicht. Also müssen andere Lösungen her. Aber man wächst ja mit seinen Aufgaben.

[nightcrawler]

Im normalen Xbase++ Umfeld kann man das ja mit File() prüfen, ob eine DBf existiert. Aber wie löst man sowas elegant unter ADS? Wenn ich mit DbUsearea() versuche eine DBF zu öffnen, die nicht da ist, dann gibt es einen 8999 zurück. Den gibt es aber auch bei anderen Probleme zurück, könnte also Verwirrung stiften.

Bei ADS kommt eine ADS Fehlermeldung (7008 - ich weiß jetzt nicht, ob Xbase++ hier die native Meldung unterdrückt und die Schutzverletzung einfach ausspuckt). Jegliche direkten Dateizugriffe sollten bei Client/Server vermieden werden, weil man damit wieder einen Schutzmechanismus aushebeln muss, damit es geht.
Bei Verwendung eines Dictionaries prüft man nicht die physik. Datei, sondern die System Views:

Code: Alles auswählen

select count(*) from system.tables where name like 'mytable'

oder

Code: Alles auswählen

if not exists (select name from system.tables where name like 'mytable') then
  create table mytable(id integer, test char(40));
end if;

[Tom]

Ergänzend zu Joachims Anleitung:

1. Man muss sich schon die Frage stellen, warum eine Tabelle nicht existiert/existieren kann, von der man das eigentlich erwartet. Wenn man vergessen hat, sie in das ADD einzupflegen, muss das nachgeholt werden. Wenn es eine Tabelle ist, die überhaupt nicht über die ADS geöffnet werden soll, muss man anders agieren, etwa über Low-Level-Operationen.

2. Man kann die Öffnungsoperationen auch in Sequenzen hängen, so dass der Laufzeitfehler nicht entsteht bzw. zum Aufruf des Fehlersystems führt. Das hat aber den Nachteil, dass man nicht weiß, warum die Tabelle nicht geöffnet werden konnte. Und dass man nicht direkt reagieren kann, wenn man z.B. herausbekommt, dass die Tabelle nicht geöffnet werden konnte, weil sie im ADD fehlt. Warum fehlt sie dort? Siehe oben.

Entscheidend scheint mir zu sein, dass es paradigmatische Unterschiede gibt, wenn man mit dem ADD arbeitet. Siehe Thread zum ADD.

[Manfred]

Ich bin erst dabei mich mit dem ADS ein wenig zu beschäftigen. Bisher ist es bei mir so, dass ich die EXE Datein nebst DLL ausliefere und dann beim ersten Ausführen alle DBF usw. erzeuge. Sprich, meine Datenbankklasse weiß genau was wo stehen muß und baut sich im Notfall alles selbst auf. Deshalb die Probleme jetzt. Ich muß also meine klasse nach und nach für den ADS anpassen um sowas auch zu erschlagen. Einiges habe ich ja schon geschafft.

[Jan]

wie schon woanders und von Jan erwähnt, DD ist Vorschrift und dann klappen die Low Level Funktionen nicht.

Das muß ich ein wenig korrigieren. Ja, DD ist Vorschrift. Aber das ist nicht der eigentliche Grund, warum LowLevel-Funktionen nicht funktionieren. Der Grund ist, das die gesamte Partition mit den DD und den dbf für die User Zugriffsbeschränkt ist. Daher können die z. B. mit File() nicht nachsehen, ob eine dbf oder eine cdx schon da ist - schlicht weil die die Dateien garnicht sehen können.

Jan

[brandelh]

und das ist auch gut so, sonst kann ein gewitzer Spion mal so eben alles kopieren oder der Saboteur einiges löschen.

[Jan]

Hubert,

genau das ist der Sinn der Sache. Bislang ging das, weil man bei direkten FOXCDX-Zugriff halt die Zugänge schlecht (OK, garnicht) beschränken kann. Mit ADS geht das aber natürlich.

Jan

[brandelh]

Hubert,
genau das ist der Sinn der Sache.

das meinte ich