prüfen ob DBF existiert
Moderator: Moderatoren
- Manfred
- Foren-Administrator
- Beiträge: 21189
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
prüfen ob DBF existiert
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.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: prüfen ob DBF existiert
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.
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.
Herzlich,
Tom
Tom
- Manfred
- Foren-Administrator
- Beiträge: 21189
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: prüfen ob DBF existiert
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.
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.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- nightcrawler
- 1000 working lines a day
- Beiträge: 651
- Registriert: Di, 24. Apr 2012 16:33
- Wohnort: 72184 Weitingen
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 96 Mal
- Kontaktdaten:
Re: prüfen ob DBF existiert
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.Manfred hat geschrieben: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 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'
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
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: prüfen ob DBF existiert
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.
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.
Herzlich,
Tom
Tom
- Manfred
- Foren-Administrator
- Beiträge: 21189
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: prüfen ob DBF existiert
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.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Jan
- Marvin
- Beiträge: 14653
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: prüfen ob DBF existiert
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.Manfred hat geschrieben:wie schon woanders und von Jan erwähnt, DD ist Vorschrift und dann klappen die Low Level Funktionen nicht.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15696
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: prüfen ob DBF existiert
und das ist auch gut so, sonst kann ein gewitzer Spion mal so eben alles kopieren oder der Saboteur einiges löschen.
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14653
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: prüfen ob DBF existiert
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15696
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: prüfen ob DBF existiert
das meinte ichJan hat geschrieben:Hubert,
genau das ist der Sinn der Sache.
Gruß
Hubert
Hubert