VFP9.0 Zugriff auf Database
Alexander Schmid
Vielleicht eine etwas blï¿œde Frage, aber ich komme nicht dahinter, was
Sache ist.
Ich habe eine Programm, geschrieben noch in VFP5.0. Wenn ich das
Programm installiere und dann ￜber das Menￜ starte und das noch einmal
mache, also die EXE-Datei zweimal im selben Verzeichnis gestartet habe,
kommt zwar ein einziges Mal ein "Access denied"-Fenster, aber danach
kann ich unabhï¿œngig in beiden gestarteten Programmen arbeiten.
Wenn ich dasselbe machen mit dem Programm geschrieben in VFP9.0,
erscheint beim 2. Aufruf: "File access is denied for
c:\mydir\myprog.dbc" Das kann ich zwar wegklicken, aber danach prasseln
zig Fehlermeldungen auf mich ein, verursacht durch eine Tabellenabfrage.
Klicke ich alle weg, und versuche dann irgend eine Maske zu ï¿œffenen,
erscheint wieder die Meldung "access denied for myprog.dbc".
Warum verhï¿œlt sich VFP9.0 diesbezï¿œglich so anders? Ich mï¿œchte mein
Programm in einem shared Directory auf einem Server installieren, wo
drei Leute gleichzeitig drauf zugreifen kï¿œnnen. Ich vermute mal, ich
werde hier mit der neuen Version in VFP9.0 in Probleme laufen. Ich habe
mal als erstes einen "OPEN DATABASE myprog SHARED" vor dem ersten
Tabellenï¿œffnen eingebaut. Resultat Null.
Danke im Voraus fï¿œr Eure Hilfe
Gruss
Alex Schmid
KNECHT + CO.
Matthias Kahlert
> Warum verhï¿œlt sich VFP9.0 diesbezï¿œglich so anders? Ich mï¿œchte mein
> Programm in einem shared Directory auf einem Server installieren, wo
> drei Leute gleichzeitig drauf zugreifen kï¿œnnen. Ich vermute mal, ich
> werde hier mit der neuen Version in VFP9.0 in Probleme laufen. Ich habe
> mal als erstes einen "OPEN DATABASE myprog SHARED" vor dem ersten
> Tabellenï¿œffnen eingebaut. Resultat Null.
Schreib doch mal irgendwo ganz am Anfang im Hauptprogramm rein "SET
EXCLUSIVE OFF" (und natï¿œrlich nachschauen, ob das dann nicht irgendwo
wieder auf ON gestellt wird). Eventuell steht ja auch in der Datei
"config.fpw" irgendwo ein "EXCLUSIVE=ON" drin, das dann auch in
"EXCLUSIVE=OFF" ï¿œndern.
--
Matthias
Olaf Doschke
wenn Applikationen fï¿œr Multiuserbetrieb unter VFP9 nicht funktionieren
wï¿œrden,
wï¿œrde das bekannt sein.
Zusï¿œtzlich zu den Tipps von Matthias: foxuser.dbf?
config.fpw mit RESOURCE=OFF eincompilieren in die EXE.
Tschￜￜ, Olaf.
Alexander Schmid
Hallo Matthias
Danke fï¿œr die schnelle Antwort. Schlafen VFP-Programmier nie :-)
Spï¿œssle beiseite. SET EXCLUSIVE war auf OFF, aber RESOURCE war's. Ich
finde allerdings die Meldung "access denied for mydatabase.dbc" in
deisem Fall etwas irrefï¿œhrend. Aber eigentlich hï¿œtte ich nach Jahren des
Programmierens in dieser Sprache selbst drauf kommen mï¿œssen. Wenn der
Fehler dubios ist, hat es in 50 % der Fï¿œlle mit der FOXUSER-Dbf zu tun. :-)
Nochmals Danke und gute Nacht
Alexander Schmid
KNECHT + CO.
Olaf Doschke schrieb:
Alexander Schmid
und jetzt habe ich den gleichen Fehler wieder. RESOURCE ist OFF. Sobald
der erste Zugriff auf eine Tabelle in der Database erfolgt, kommt die
Meldung "file access is denied for mydatabase.dbc". Ist mir nicht
erklï¿œrlich. Vielleicht noch eine Idee?
Gruss
Alex Schmid
KNECHT + CO.
Olaf Doschke schrieb:
Olaf Doschke
> Meldung "file access is denied for mydatabase.dbc". Ist mir nicht
> erklï¿œrlich. Vielleicht noch eine Idee?
Error 1705:
file access is denied
You have attempted to write to a file that is write-protected or open
exclusively by another.
Also ist Deine Datenbank vielleicht im Projekt mit eincompiliert? Dann nimmt
die VFP Runtime die eincompilierte DBC und DBFs und kann daraus nur lesen.
Ist irgendeine Datei der Datenbank readonly? Dann kï¿œnnte auch der Fehler
kommen. Hast Du die Datenbank evtl. in Deinem Projekt mit drin, zwar von der
eincompilierung ausgeschlossen und hast in der IDE exklusiven Datenzugriff
in den Optionen an (SET('EXCLUSIVE') ist ON)? Dann bist Du derjenige, der
immer dann wenn Du im Projekt arbeitest die Datenbank sperrt.
Wenn kein Schreibschutz besteht muￜ irgendjemand die Datenbank exklusiv
offen haben.
Tschￜￜ, Olaf.
Axel Netzband
deine tabellen zugegreift ohne dass sie zu diesem zeitpunkt geï¿œffnet
sind? falls fox sie findet klappt der sql - select nï¿œmlich trotzdem, nur
werden die tabellen excl geï¿œffnet.
setz doch mal ein "list status to file 'status.txt'" in dem betreffenden
programmteil ab.
gruss aus kassel
axel
Axel Netzband
Axel Netzband
Axel Netzband
kￜnnte es sein, daￜ irgendwo ein sql - select gefahren wird, das auf
Olaf Doschke
> werden die tabellen excl ge�ffnet.
Das h�ngt dann von der Einstellung SET('EXCLUSIVE') ab. Und wie vieles ist
das von eine Einstellung je Datasession. Default ist OFF f�r private, ON f�r
die globale Datasession. Und in den Foxpro IDE Optionen ist der Default
ebenso ON.
In der IDE sollte man unter Options das Off stellen und mit Set As Default
dauerhaft so einstellen. Und das sollte man dann nach VFP Neustart auch mal
pr�fen. Ich hatte auch schon wegen Policies keine Dauerhafte Sepicherung der
Optionen mittels Set As Default.
Wegen dem Default ON f�r die globale Datasession geh�rt halt in den
Programmstart SET EXCLUSIVE OFF oder in ein config.fpw EXCLUSIVE=OFF. OPEN
DATABASE ... SHARED �ffnet die DBC Datei shared, nicht mehr, nicht weniger.
Das "vererbt" sich also nicht automatisch auf alle weiteren
Tabellen�ffnungsoperationen. Jegliches �ffnen von Tabellen per USE ohne
explizite Angabe von SHARED oder EXCLUSIVE richtet sich nach der Einstellung
SET('EXCLUSIVE') Auch jedes indirekte �ffnen von DBF-Dateien z.B. per
SQL-Select, Insert, Update oder Delete, daher ist die EXCLUSIVE-Einstellung
doch sehr zentral wichtig.
Tsch��, Olaf.
Stefan Wuebbe
> Ich habe heute morgen nochmals testhalber meine Anwendung installiert
> und jetzt habe ich den gleichen Fehler wieder. RESOURCE ist OFF. Sobald
> der erste Zugriff auf eine Tabelle in der Database erfolgt, kommt die
> Meldung "file access is denied for mydatabase.dbc". Ist mir nicht
> erklï¿œrlich. Vielleicht noch eine Idee?
Der Fehler hat jedenfalls nichts mit Set('Resource') zu tun.
Mï¿œglicherweise wird deine datenbank.DBC versehentlich von
einer Vfp Instanz (Laufzeit oder IDE) versehentlich exklusiv
geï¿œffnet, sodass die nï¿œchste Instanz den o.g. Fehler meldet.
Wenn es sich bei der Ersten um deine Anwendung handelt, hilft
es vielleicht die Datenbank explizit Shared zu ï¿œffnen.
Also z.B. frï¿œh im "main.prg" ein "Open Database xy Shared",
noch bevor irgendwelche Formulare und ihre Datenumgebungen
starten.
hth
-Stefan
Axel Netzband
>>sind? falls fox sie findet klappt der sql - select n锟絤lich trotzdem, nur
>>werden die tabellen excl ge锟絝fnet.
>
>
> Das h锟絥gt dann von der Einstellung SET('EXCLUSIVE') ab. Und wie vieles ist
> das von eine Einstellung je Datasession. Default ist OFF f锟絩 private, ON f锟絩
> ebenso ON.
>
> In der IDE sollte man unter Options das Off stellen und mit Set As Default
> dauerhaft so einstellen. Und das sollte man dann nach VFP Neustart auch mal
>
> doch sehr zentral wichtig.
>
>
>
hi olaf,
hab mich vielleicht nicht so genau ausgedr锟絚kt.
ich meinte nachfolgendes:
** beispiel prg **
&& **************************************
&& config
CLEAR
SET EXCLUSIVE OFF && !!!
SET SAFETY OFF
&& los geht's
LOCAL lcDeinPfad, llSwitch
lcDeinPfad = 'c:\temp\' && exist. verz.
*llSwitch = .T. && INTO array -> klappt
llSwitch = .F. && INTO Cursor -> fehlermeldung
&& tabelle erzeugen
CREATE TABLE (lcDeinPfad + 'test.dbf') (testfeld C(10))
APPEND BLANK
REPLACE testfeld WITH 'exclusive?'
FLUSH
USE && Tabelle schlie锟絜n
&& *******************************************************
&& SQL - Abfrage
SET PATH TO (lcDeinPfad)
IF (llSwitch)
SELECT * FROM test INTO ARRAY a_temp
ELSE
SELECT * FROM test INTO CURSOR c_temp
ENDIF
&& man beachte den aktuellen arbeitsbereich
DISPLAY STATUS
WAIT WINDOW 'STATUS 1' TIMEOUT 3
CLEAR
&& arbeitsbereich 2 geht sowieso nicht, aber auch 1 & 3(neuer) liefert:
'file is in use'
&& Z.B. Arbeitsbereich 1
SELECT 1
DISPLAY STATUS
WAIT WINDOW 'STATUS 2' TIMEOUT 3
CLEAR
&& einfach mal 锟絝fnen und... RUMS !!
USE 'test.dbf' ALIAS mytest SHARED
&& wenn jetzt 'c_temp' mit 'use' abgeschossen wird, geht's wieder
&& ALso:
IF (USED('c_temp'))
SELECT c_temp
USE
ENDIF
SELECT 1
USE 'test.dbf' ALIAS mytest SHARED
DISPLAY STATUS
RELEASE a_temp
CLOSE DATABASES
RETURN
Olaf Doschke
> USE 'test.dbf' ALIAS mytest SHARED
Falsch, es gibt hier "File is in Use", nicht "Access Denied".
einen anderen ALIAS zu nutzen hilft nur gegen den Fehler "Alias is in use",
gegen "File is in use" hilft aber AGAIN:
USE 'test.dbf' ALIAS mytest SHARED AGAIN
D.h. per Default (ohne explizite Angabe von ALIAS und AGAIN) m�chte VFP
nicht nur Aliase eineindeutig, sondern weist auch darauf hin, da� eine Datei
schon offen ist (wenn auch shared!). Nur AGAIN �berredet in dem Fall VFP die
Tabelle nochmal shared in derselben Datasession zu �ffnen. 'File is in Use'
ist auf jeden Fall nicht der Fehler, der darauf hindeutet, da� eine DBF
woanders oder bei einem selbst exklusiv offen ist. Alexander kreigt aber den
"richtigen" Fehler: "file access is denied".
Was Alexanders Problem angeht vermute ich wie Stefan W�bbe, da� die DBC oder
zumindest ein DBF davon in einer VFP Sitzung oder einem ganz anderen
Programm versehentlich exklusiv ge�ffnet sind. Selbst wenn man in seiner
Applikation alles richtig macht, ist man dagegen nie gefeit. Oder der andere
Grund: Die Dateien sind halt Readonly, oder in einem Systemverzeichnis, was
Readonly ist oder mit eincompiliert.
Tsch��, Olaf.
Olaf Doschke
zu demonstrieren:
ON ERROR ? Message()
Use browser IN 0 Shared
* geht nicht
Use browser IN 0 Alias browser2 Shared
* geht
Use browser IN 0 Alias browser3 Shared Again
Set
Tsch��, Olaf.
Matthias Kahlert
> Ich habe heute morgen nochmals testhalber meine Anwendung installiert
> und jetzt habe ich den gleichen Fehler wieder. RESOURCE ist OFF. Sobald
> der erste Zugriff auf eine Tabelle in der Database erfolgt, kommt die
> Meldung "file access is denied for mydatabase.dbc". Ist mir nicht
> erklï¿œrlich. Vielleicht noch eine Idee?
Moment mal, Du schreibst, Du hast die Anwendung nochmal "installiert".
Etwa nach "c:\Programme\"? Hat Dein User Schreib/Leserechte auf das
Installationsverzeichnis? Bei Windows Vista ff. ist dies nicht unbedingt
gegeben!
--
Matthias
Alexander Schmid
Danke für den Hinweis, aber steht drin. Ich habe vor dem USE-Befehl, der die
erwähnte Fehlermeldung auslöst, zum Test SET ("EXCLUSIVE") abgefragt und es
war OFF. Sofort danach kam der USE-Befehl auf eine Tabelle der Database und
dann der Fehler "access denied".
Alexander Schmid
installiert.
Ich benutze Windows XP. Leider komme ich frühestens morgen Freitag wieder
dazu weiterzutesten.
Alexander Schmid
Erstmal Danke an alles für Ihre Anregung. Leider kann ich frühestens morgen
Freitag weitertesten. Mal ne ganz generelle Frage zum Problem.
Ausgangslage: Eine Anwendung (exe) mit einer DBC und ein paar Tabellen drin.
Im File Config.fpw ist RESOURCE = OFF und im Programmcode SET EXCLUSIVE = OFF
zudem haben alle Forms DATASESSION = 1 (Default und die ist auf Global
gesetzt.). Die Anwendung läuft unter VFP9.0 und Windows XP und wird im
Verzeichnis c:\meineapp installiert.
Frage: So eine Anwenung kann man auf dem selben PC problemlos MEHRMALS
starten. Und ich meine nur starten und eine Tabelle öffnen und ein Menü
anzeigen. Formulare werden noch keine geöffnet. Das müsste doch möglich sein?
Horst Kühn
> anzeigen. Formulare werden noch keine geöffnet. Das müsste doch möglich sein?
Kurz und bündig: klaro
Ansonsten hab ich jetzt keine weitere Lösungsmöglichkeit für Dich, nur
eine nebulöse Anregung für Dich und andere Mitüberlegende: Is das denn
wirklich gesichert, das das Problem unter Fox 9 besteht aber nicht unter
Version 5? Und unter gleichen sonstigen (Betriebsystem) Bedingunge ?
Dann bräuchte man doch "nur" gucken wo es denn da Unterschiede gibt. Da
bin ich leider nicht versiert genug zu, aber in Sachen SQL im Fox ist
doch einiges rigoroser geworden, sprich sicherer womit aber einhergeht
das nicht alle SQL betreffenden Befehle wie früher ohne Fehlermeldung
(also fehlerhafter) durchlaufen.
Vielleicht liegt der Wurm ja hier begraben
m2p
Horst
Olaf Doschke
Das sollte laufen k�nnen, auch mehrfach gestartet.
Alles nur in der general Datasession abzuwickeln ist nur meines Erachtens
nach ungeschickt, weil Du damit leicht mal zumindest den von Axel Netzband
beschriebenen Fehler kriegen kannst, eine Tabelle nicht ein zweites mal
�ffnen zu k�nnen. Allerdings dann mit Fehler "File is in use", nicht "File
access is denied".
Da Du auf C:\ installierst und nicht sachgem�� unter C:\Programme m�gen
NTFS-Rechte greifen, die dem User Schreibzugriffe in dieses
Installationsverzeichnis nicht geben, weil's ja vom Administratoraccount vom
Setup angelegt ist. Abhilfe mag dann schaffen, da� die Benutzer als
Hauptbenutzer des Rechners eingerichtet sind, dann gibt es wieder etwas mehr
Rechte, die andere Variante w�re, dem Setup eben mitzugeben, Schreibrechte
im Installationsordner zu vergeben.
Unter ISE hast Du da als Platzhalter [InstallDir] klick mal rechts drauf,
dann kannst Du dort Rechte vergeben, die dann beim Setup gesetzt werden.
Es ist allerdings wirklich keine Kunst mehr, ins ProgramFiles Verzeichnis zu
installieren und die Daten unter �ffentliche Anwendungsdaten zu legen. Dann
bist Du wirklich sauber.
Tsch��, Olaf.
Horst Kühn
> Auￜer, daￜ es SET EXCLUSIVE OFF und nicht = OFF heiￜt, ja.
bzw. es kann auch in der config.fpw stehen und dann : EXCLUSIVE = OFF
Horst
Alexander Schmid
"Olaf Doschke" wrote:
> Außer, daß es SET EXCLUSIVE OFF und nicht = OFF heißt, ja.
Danke. War nur ein Tippfehler ;-)
> Alles nur in der general Datasession abzuwickeln ist nur meines Erachtens
> nach ungeschickt... [snip]
Das stimmt. Aber ich habe hier eine gewachsene Anwendung, die bis auf FoxPro
2.6-Zeiten zurückgeht. Ich kann hier nicht grundlegende Umstellungen machen,
obwohl ich das gerne täte. Aber ich schätze den Aufwand dafür als zu gross
ein und bezahlen wird mir das auch niemand.
> Unter ISE hast Du da als Platzhalter [InstallDir] klick mal rechts drauf,
> dann kannst Du dort Rechte vergeben, die dann beim Setup gesetzt werden.
Das ist interessant. Danke, habe ich nicht gewusst.
> Es ist allerdings wirklich keine Kunst mehr, ins ProgramFiles Verzeichnis zu
> installieren und die Daten unter öffentliche Anwendungsdaten zu legen. Dann
> bist Du wirklich sauber.
Die neue Version mit VFP9.0 wird allerdings in die ProgramFiles-Verzeichnis
installiert. Die alte VFP5.0-Version aber noch unter c:\meineapp. Wenn der
Benutzer zusätzlich zu den 12 Versionen die er mit dem Update überspringt,
auch noch auf das ProgramFiles-Verzeichnis wechseln soll, gibt es
möglicherweise nur wieder Unannehmlichkeiten, die ich vermeiden will. In der
Informatik gilt bekanntlich ja Hofstettersches Axiom: "Nichts funktioniert!"
;-)
Mit den Anwendungsdaten hast Du natürlich auch recht. Aber ich muss zugeben,
selbst auf die Gefahr hin hier ein wenig dümmlich dazustehen, ich raff das
Konzept von Microsoft in welchen Verzeichnissen die Daten gehalten werden
sollen, nicht so recht. Ich hatte das entsprechende Dokument von Microsoft
heruntergeladen und studiert und hatte damit dann experimentiert und das
Resultat war: Nichts lief. Ich hatte damals aber nicht nur Anwendungsdaten
für alle Benutzer, sondern auch noch Daten, die nur für jeden einzelnen
Anwender galten. Ist jetzt ein wenig Off-topic, Pardon.
Olaf Doschke
"Alexander Schmid" <Alexand...@discussions.microsoft.com> schrieb im
Newsbeitrag news:F7EBA985-9AE0-46D6...@microsoft.com...
> Hallo Olaf
>
> "Olaf Doschke" wrote:
> Danke. War nur ein Tippfehler ;-)
>
>> Alles nur in der general Datasession abzuwickeln ist nur meines Erachtens
>> nach ungeschickt... [snip]
> Das stimmt. Aber ich habe hier eine gewachsene Anwendung, die bis auf
> FoxPro
> machen,
> obwohl ich das gerne t�te. Aber ich sch�tze den Aufwand daf�r als zu gross
> ein und bezahlen wird mir das auch niemand.
>
>> Unter ISE hast Du da als Platzhalter [InstallDir] klick mal rechts drauf,
>> dann kannst Du dort Rechte vergeben, die dann beim Setup gesetzt werden.
> Das ist interessant. Danke, habe ich nicht gewusst.
>
>> Es ist allerdings wirklich keine Kunst mehr, ins ProgramFiles Verzeichnis
>> zu
>> bist Du wirklich sauber.
> Die neue Version mit VFP9.0 wird allerdings in die
> ProgramFiles-Verzeichnis
> installiert. Die alte VFP5.0-Version aber noch unter c:\meineapp. Wenn der
> auch noch auf das ProgramFiles-Verzeichnis wechseln soll, gibt es
> Informatik gilt bekanntlich ja Hofstettersches Axiom: "Nichts
> funktioniert!"
> ;-)
>
> zugeben,
> selbst auf die Gefahr hin hier ein wenig d�mmlich dazustehen, ich raff das
> Konzept von Microsoft in welchen Verzeichnissen die Daten gehalten werden
> sollen, nicht so recht. Ich hatte das entsprechende Dokument von Microsoft
> heruntergeladen und studiert und hatte damit dann experimentiert und das
> Resultat war: Nichts lief. Ich hatte damals aber nicht nur Anwendungsdaten
Olaf Doschke
> zugeben,
> selbst auf die Gefahr hin hier ein wenig d�mmlich dazustehen, ich raff das
> Konzept von Microsoft in welchen Verzeichnissen die Daten gehalten werden
> sollen, nicht so recht. Ich hatte das entsprechende Dokument von Microsoft
> heruntergeladen und studiert und hatte damit dann experimentiert und das
> Resultat war: Nichts lief. Ich hatte damals aber nicht nur Anwendungsdaten
> Anwender galten. Ist jetzt ein wenig Off-topic, Pardon.
Macht ja nix. Es ist auch ein ziemlich verkompliziertes Thema.
Ich kann da auf mein Projekt verweisen: http://vfptweetapi.codeplex.com
Darin findest Du in libFilesystem.prg zwei Prozeduren, die den Pfad lokaler
Applikationsdaten
und den Pfad gemeinsamer Applikationsdaten ermitteln.
Entscheidender als der Code daf�r ist, da� ich mich entschieden habe die
Datenbank
erst beim Starten der Applikation anzulegen, in diesem Projekt in jedem Fall
im
LocalAppData Pfad, was die Datenbank an User und PC bindet, die typsiche
Situation f�r Privatanwender, auch geeignet f�r den Familien-PC, wo jeder
sein
eigenes Profil hat, dann kriegt auch jeder seine eigene Datenbank. Und hat
damit
auch keinesfalls ein Rechteproblem.
W�rde ich daf�r ein Setup erstellen, w�rde dieses auch nach wie vor nicht
eine Datenbank
erstellen, sondern erst die Applikation selbst.
Ich werde sp�ter anbieten neue Datenbanken anzulegen oder bestehende an
andere Orte
zu verschieben, wobei dann der Common-Appdata Pfad ein Default sein kann.
Der User ist ja auch durchaus bei einem Standard-Installer mit der Option
den
Installationspfad zu �ndern in der Lage ein Installationsverzeichnis
au�erhalb des
ProgramFiles Ordners anzugeben. So falsch ist das also ja nicht, nur mu� man
vom Installer auch dann u.U. immer noch Rechte f�r Benutzer einr�umen, der
Besitzer des Installationsordners ist logischerweise auch dann erst mal ein
Nutzer
der Adminstratorengruppe. Alle Rechte - insbesondere Schreibrechte -hat erst
einmal immer nur der.
Tsch��, Olaf.
Alexander Schmid
Jetzt konnte ich mich weiter um meinen Fehler kï¿œmmern. Ich habe nun die
Ursache fï¿œr die Meldung "access denied for myprog.dbc" gefunden. Es lag
an folgendem Code (hier gekï¿œrzt)
PROCEDURE FileCheck
LOCAL mdbf
mdbf = 0
ON ERROR DO FileCheck_Error WITH ERROR(), mdbf
mdbf = 1
USE dfeh01
mdbf = 2
USE dfeh02
USE
ON ERROR DO err_routine WITH ERROR(), MESSAGE(), LINENO(), PROGRAM()
RETURN
Dies fï¿œhrt zum oben genannten Fehler. Ich habe am Ende der PROCEDURE nun
die Befehlszeile
CLOSE DATABASES ALL
eingefï¿œgt. Nachher lief alles, wie erwartet. SET EXCLUSIVE war auf OFF
gesetzt und RESOURCE auf ON.
Warum dann in einer nachfolgenden Prozedur (hier auch wieder gekï¿œrzt)...
PROCEDURE r_einstell
USE dfeh38
IF RECCOUNT("DFEH38") = 0
APPEND BLANK
ENDIF
...
USE dfeh05 NOUPDATE
mf_kanton = IIF(EMPTY(kanton),"AARGAU",UPPER(TRIM(kanton)))
USE
RETURN
...mit einer ï¿œhnlichen Struktur der USE-Befehl das nicht passiert,
verstehe ich nicht ganz.
Nochmals Danke an alle, die mitdiskutiert haben.
Gruss
Alex
Olaf Doschke
freut mich ja, aber...
> PROCEDURE FileCheck
> LOCAL mdbf
> mdbf = 0
> ON ERROR DO FileCheck_Error WITH ERROR(), mdbf
> mdbf = 1
> USE dfeh01
> mdbf = 2
> USE dfeh02
> USE
> ON ERROR DO err_routine WITH ERROR(), MESSAGE(), LINENO(), PROGRAM()
> RETURN
>
> Dies fï¿œhrt zum oben genannten Fehler.
Wenn Du jetzt noch verrï¿œtst an welcher Stelle?
Und wenn Du noch verrï¿œtst, ob die Tabellen dfeh01 und dfeh02
zur Datenbank myprog.dbc gehï¿œren?
Und wenn Du auch noch den Code von FileCheck_error verrï¿œtst
Vielleicht kann man Dir dann aufzeigen, was eigentlich den
Fehler ausgelï¿œst hat.
Tschￜￜ, Olaf.
Alexander Schmid
Ich konnte Dir leider nicht frï¿œher antworten. Meine Beschreibung war
etwas ungenau. Unten der komplette Code (sinnvoll gekï¿œrzt). Der Fehler
trat in der Prozedure r_einstell auf, beim ï¿œffnen der Tabelle USE
dfeh38. Meine Korrektur ist im unteren Code nicht ersichtlich. Ich habe
in der Prozedur FileCheck am Ende, vor dem RETURN, CLOSE DATABASES ALL
eingefï¿œgt. Alle Tabellen gehï¿œren zur Database "mydatabase". Ich erkenne
im Code keine offensichtliche Fehler (Kunststï¿œck sonst hï¿œtte ich diesen
Thread ja nicht schreiben mï¿œssen ;-). In der Prozedur "FileCheck_Error"
wï¿œrde ich heute nach dem LPARAMETER ein ON ERROR einfï¿œgen und am Ende
ein ON ERROR ... Da aber diese beiden Befehle in der Prozedur r50index
stehen, erachte ich das als nicht zu tragisch.
Beim Testen habe ich ï¿œbrigens festgestellt, dass die Prozedur
"FileCheck_Error" nicht in r50index verzwiegen ist, da kein Fehler vorlag.
Gerne gebe ich Dir weitere Details.
Gruss
Alex
---------------------------------------------------
Hauptprogramm
DO FileCheck
DO r_einstell
Prozeduren
PROCEDURE FileCheck
LOCAL mdbf
mdbf = 0
ON ERROR DO FileCheck_Error WITH ERROR(), mdbf
mdbf = 1
USE dfeh01
mdbf = 2
USE dfeh02
USE
ON ERROR DO err_routine WITH ERROR(), MESSAGE(), LINENO(), PROGRAM()
RETURN
PROCEDURE FileCheck_Error
LPARAMETER errornum, mdbf
IF errornum = 114
DO r50index IN pfeh50 WITH "J", mdbf
RETRY
ENDIF
RETURN
PROCEDURE r_einstell
USE dfeh38
IF RECCOUNT("DFEH38") = 0
APPEND BLANK
*-- Anpassen der Vorgaben gemï¿œss Hilfetext "Einstellungen"
REPLACE ortscode WITH .F.
REPLACE novoplzort WITH .F.
ENDIF
STORE ortscode TO mf_ortscd
STORE novoplzort TO mf_novoplzort USE dfeh05 NOUPDATE
mf_kanton = IIF(EMPTY(kanton),"AARGAU",UPPER(TRIM(kanton)))
USE
RETURN
PROCEDURE r50index
PARAMETERS m.packflag, mdbf
ON ERROR
CLOSE DATABASES ALL OPEN DATABASE florian EXCLUSIVE
IF mdbf = 1 OR mdbf = 0
REMOVE TABLE dfeh01 DELETE FILE dfeh01.cdx
USE dfeh01 EXCLUSIVE
WAIT WINDOW "Indizes fï¿œr " + ALIAS() + " werden erstellt" NOWAIT
INDEX ON CHRTRAN(name,"ￜￜￜ","aou") + vorname TAG navo
INDEX ON laufnr TAG laufnr
IF m.packflag = "J"
PACK
ENDIF
USE ADD TABLE dfeh01 ENDIF
IF mdbf = 0 OR mdbf = 2 REMOVE TABLE DFEH02
DELETE FILE dfeh02.cdx
USE dfeh02 EXCLUSIVE
WAIT WINDOW "Indizes fï¿œr " + ALIAS() + " werden erstellt" NOWAIT
INDEX ON gradcd TAG gradcd
INDEX ON laufnr TAG laufnr
IF m.packflag = "J"
PACK
ENDIF
USE
ADD TABLE dfeh02
ENDIF WAIT WINDOW " " TIMEOUT .05 ON ERROR DO
err_routine WITH ERROR(),MESSAGE(),LINENO(),PROGRAM()
RETURN
Olaf Doschke schrieb:
Olaf Doschke
>Unten der komplette Code (sinnvoll gek�rzt).
Du �ffnest ja nur testweise dfeh01 und dfeh02 mit Errorhandling durch
FileCheck_Error. Wenn da nichts passiert, hast Du am Ende von dem Code her
keine Tabelle offen.
Wenn da ein Fehler ist und Du in FileCheck_Error die Indexroutine aufrufst,
dann w�rde ich an dessen Ende die Datenbank schlie�en, und dann neu shared
�ffnen, nicht exklusiv offen behalten, das ist das Problem. Auch wenn dfeh38
bestandteil von myprog.dbc und nicht von florian.dbc w�re, ein USE mit
tabellenname ohne Datenbank!tabellenname sucht erst einmal im aktiven DBC,
ob darin die Tabelle zu finden ist...
Tsch��, Olaf.
Jürgen Wondzinski
kannst du mir den Sinn des Codes in der r50index Routine erklären?
Warum machst du ein REMOVE TABLE, löschst dann einfach physikalisch die CDX,
was dann in der nächsten Zeile zu einem Fehler führen muss ("Strukturierter
Index nicht gefunden"), um dann die Index-Tags wieder dazuzufügen. Dann
kommt optional ein PACK, der wiederum die Indizes nochmal aufbaut, und dann
wird die Tabelle wieder der Datenbank zugefügt.
Is alles ein bischen verquer.
Wobei diese Routine ja auch noch nur angesprungen wird, wenn Fehler 114
("Index does not match the table") auftaucht, was ein eher sehr seltener
Fehler ist, der eigentlich nur durch wüstes Umkopieren verschiedener
Tabellenversionen entstehen kann.
Generell solltest du dir mal das TRY/CATCH zu Gemüte führen, anstatt all
diese Umwege mit verschiedensten ON ERROR Belegungen zu gehen.
--
wOOdy
Visual FoxPro Technologieberater
Microsoft "Most Valuable Professional" 1996 bis 2009
"*´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´. (¸.·` *
..·`.Visual FoxPro: It's magic !
(¸.·``··*
Alexander Schmid
Mein Codebeispiel ist durch das Kopieren leider falsch umgebrochen
worden. Dadurch waren ein paar Details nicht sehr gut zu sehen. Hier
nochmals, jetzt hoffentlich korrekt umgebrochen:
PROCEDURE r50index
PARAMETERS m.packflag, mdbf
ON ERROR
CLOSE DATABASES ALL
OPEN DATABASE florian EXCLUSIVE
IF mdbf = 1 OR mdbf = 0
REMOVE TABLE dfeh01
DELETE FILE dfeh01.cdx
USE dfeh01 EXCLUSIVE
WAIT WINDOW "Indizes für " + ALIAS() + " werden erstellt" NOWAIT
INDEX ON CHRTRAN(name,"äöü","aou") + vorname TAG navo
INDEX ON laufnr TAG laufnr
IF m.packflag = "J"
PACK
ENDIF
USE
ADD TABLE dfeh01
ENDIF
... [weiterere ähnlicher Code weggelassen]
ON ERROR DO err_routine WITH ...
Jürgen Wondzinski schrieb:
> Hallo Alex,
>
>
> Warum machst du ein REMOVE TABLE, löschst dann einfach physikalisch die
> CDX, was dann in der nächsten Zeile zu einem Fehler führen muss ...
Der REMOVE entfernt die Tabelle aus der Datenbank. Das mache ich damit
bei nachfolgenden Index-Befehl nicht die Datenbank "invalid" wird.
Pardon, aber DELETE FILE dfeh01.cdx führt hier zu keinem Fehler.
Diese Routine erfüllt zwei Zwecke, wobei man diskutieren kann, ob es
sinnvoll ist beides zusammen zu machen.
1. Wenn ein defekter Index vorliegt (Fehler 114) sollen die
Index-Dateien vollständig neu aufgebaut werden. Kein Reindex, weil der
Befehl solche Fehler nicht behebt. Darum all das Gedöns oben: Tabelle
aus Datenbank, Indexfile löschen, Tabelle exklusive öffnen und Indizes
neu aufbauen, Tabelle schliessen und Tabelle am Schluss wieder der
Datenbank dazufügen.
2. Die Prozedur packt auch alle Tabellen. Dass dies mit dem
Indexaufbauen zusammen gemacht wird, kann man diskutieren. Der Pack wird
übrigens nur ausgeführt, wenn der Benutzer einen bestimmten Menübefehl
aufruft. Dann enthält die Variable m.packflag "J" und es wird gepackt.
Jürgen Wondzinski
ich hab deinen Code schon komplett verstanden, auch mit falschen Umbrüchen.
Dadurch wird aber die Logik aber auch nicht besser ;)
Nochmal: Um die Indexe neu aufzubauen, muss die Tabelle nicht aus der
Datenbank raus, es reicht ein DELETE TAG ALL, um alle Indexinfos zu löschen.
Durch das Rausnehmen aus der DB verlierst du ja alle zusätzlichen Infos, die
erst den Sinn der DB ausmachen (Lange Feldnamen, Extra Captions,
Validierungen, Trigger...) Wenn du keine zusätzlichen Infos drinhast,
bräuchtest du die Tabelle ja erst garnicht in den DBC aufnehmen.
Wenn du nach dem Löschen der CDX Datei keinen Fehler beim nachfolgenden USE
bekommst, dann hat das drei Ursachen: a) Die DBF weiss von dem Index garnix,
es ist also kein echter Compound-Index der im Header der DBF vermerkt wäre,
b) dein Errorhandler vernichtet den Fehler ohne zu meckern; oder c) du hast
SET SAFETY OFF, dann wird dieser Fehler unterdrückt. Letzteres war mir
ehrlicherweise garnicht mehr bewusst, aber diese undokumentierte Eigenschaft
des SET SAFETY ist tatsächlich schon seit FP 2.x drinne (wie ich gerade
durch Tests feststellen musste [örgs]) Ok, abgehakt.
>> bei nachfolgenden Index-Befehl nicht die Datenbank "invalid" wird
Ich hör zum ersten Mal, dass ne Datenbank durch ein INDEX ON "invalid"
würde. Überleg mal: Wenn das normal wäre, würde sich die Erfindung einer
Datenbank nicht durchgesetzt haben... Dein Fehler muss andere Ursachen
haben.
Alexander Schmid
Danke für Deine Erläuterungen. Ich geb's zähneknirschend zu, Du hast
recht. Mein Code ist nicht gerade ein Ausbund an Eleganz. Er stammt halt
aus meinen ersten Tagen mit VFP. Und bis jetzt ist das Ding nie auf die
Schnauze gefallen und moderte zufrieden vor sich hin.
Jürgen Wondzinski schrieb:
> Nochmal: Um die Indexe neu aufzubauen, muss die Tabelle nicht aus der
> Datenbank raus, es reicht ein DELETE TAG ALL
Einverstanden.
> c) du hast SET SAFETY OFF
Genau, das war's.
> Ich hör zum ersten Mal, dass ne Datenbank durch ein INDEX ON "invalid"
> würde.
Die Meldung heisst präzise "Database is invalid. Please validate". Wird
daran liegen, dass der CDX brutal gelöscht wurde, vermute ich. Mit
DELETE TAG ALL gibt's diese Meldung nicht. Okay DELETE TAG ALL wird
mein Freund :-)
Gruss
Alex