PACK error
Norbert
-> Ernie hat eine Kunden-DBF ge�ffnet und die Bearbeitung dauert
-> Stromberg will diese Kunden-DBF ebenfalls �ffnen und bekommt den Dialog,
dass der Zugriff nicht m�glich ist, auf den Schirm (normale
Cosmos-Mitarbeiter gehen jetzt in die Kaffeek�che).
Nicht so Stromberg - ungeduldig best�tigt er permanent die Dialogtaste
"Erneut versuchen"
Irgendwann schlie�t Ernie die Kunden-DBF und Stromberg bekommt den Zugriff.
Es sei denn, dass bei Ernie in der abschliessenden Routine ein PACK auf die
Kunden-DBF ausgef�hrt wird. Dann schmiert Ernies Applikaton, im Falle einer
Zugrffsabfrage seitens Stromberg, ab! Stromberg kann hingegen in Ruhe
weiterarbeiten.
Kann da jemand unser Know-How-Defizit/Gef�lle beseitigen?
Gru�
Norbert
Hans-Peter Grözinger
> Es sei denn, dass bei Ernie in der abschliessenden Routine ein
> PACK auf die Kunden-DBF ausgef�hrt wird. Dann schmiert Ernies
> Applikaton, im Falle einer Zugrffsabfrage seitens Stromberg, ab!
Wozu ist den ein PACK hier �berhaupt notwendig?
Sowas geh�rt wie das Sichern der Daten, das Reindizieren usw. in
einen Wartungstask der exklusiven Zugriff hat. Zu dieser Zeit ist
kein weiterer Anwender angemeldet.
Wenn du etwas ausfiltern m�chtest geht das auch mit
SET DELETED ON
d.h. alle zum l�schen markierten S�tze werden nicht mehr angezeigt,
sind aber als gel�scht markiert.
Der Wartungstask PACKt dann diese S�tze und l�scht sie auch physikalisch
weg.
--
Hans-Peter Gr�zinger
TOFU ist gedankenlose Resourcenverschwendung.
http://einklich.net/usenet/zitier.htm
http://support.microsoft.com/default.aspx?scid=fh;DE;NGNetikette
Norbert
Die Kunden-DBF wird �ber den "exclusiven-Zugriff" ge�ffnet/gesperrt um ein
PACK zu erm�glichen. Wie es anders geht, ist auch klar, aber ein PACK muss
dann doch "jederzeit" m�glich sein, ohne dass die App abschmiert (h�ngen
oder C00000005!)!?
Gru�
Norbert
(HPG: die mail an dich sollte nicht sein!)
"Hans-Peter Gr�zinger" <hansp...@gmx.de> schrieb im Newsbeitrag
news:eXoxL$xdKHA...@TK2MSFTNGP06.phx.gbl...
Hans-Peter Grözinger
> Die Kunden-DBF wird �ber den "exclusiven-Zugriff" ge�ffnet/gesperrt um ein
> PACK zu erm�glichen. Wie es anders geht, ist auch klar, aber ein PACK muss
> dann doch "jederzeit" m�glich sein, ohne dass die App abschmiert (h�ngen
> oder C00000005!)!?
Und du bist sicher da� die DBF auch exklusiv ge�ffnet werden konnte?
Normalerweise meldet sich VFP wenn man etwas exklusiv ge�ffnet hat
und ein anderer auch zugreifen m�chte.
Olaf Doschke
> Irgendwann schlie�t Ernie die Kunden-DBF und Stromberg bekommt den
> Zugriff.
>
> Es sei denn, dass bei Ernie in der abschliessenden Routine ein PACK auf
> die Kunden-DBF ausgef�hrt wird. Dann schmiert Ernies Applikaton, im Falle
> einer Zugrffsabfrage seitens Stromberg, ab! Stromberg kann hingegen in
> Ruhe weiterarbeiten.
Du widersprichst Dir hier, schlie�t Ernie wirklich die DBF und macht danach
ein
PACK drauf, oder PACKst Du die (noch immer exklusiv) ge�ffnete DBF?
Wenn Du schlie�t und dann erst anschjlie�end packst, sollte Ernie einen
Zugriff nicht erlaubt Fehler bekommen, wenn wirklich Stromberg genau
den richtigen Moment erwischt die DBF dann endlich zu �ffnen.
Abegsehen davon, da� das kein C5-Fehler geben sollte, warum machst Du
�berhaupt je Exklusivzugriff bei Ernie, der damit die Tabelle nur f�r sich
hat?
Wie schon Hans-Peter anmerkte geh�rt sowas in einen separaten Task und
man arbeitet mit DELETE ON.
Tsch��, Olaf.
Norbert
kann, ist die DBF gesperrt.
Da das PACK nur im "exclusiven-Zugriff" ausgef�hrt werden kann, und ohne
Strombergs Zugriffsversuche funzt das ja auch, ist auch das sicher. Da gibt
es nur ein "open" und ein "use in"(!), also nicht "mal so, oder mal so"
Info : ist noch VFP7
Norbert
"Hans-Peter Gr�zinger" <hansp...@gmx.de> schrieb im Newsbeitrag
news:eZmd8Oyd...@TK2MSFTNGP02.phx.gbl...
Horst Kühn
> weiterarbeiten.
naja eigentlich logisch.s. den letzten Satz. Also muss Stromberg
irgendwo zwischen der Arbeit von Ernie und dem Pack von Ernie einen
Zugriff kriegen.
Wenn Stromberg in der Datei arbeiten kann, kann kein anderer ein Pack
machen.Und wenn Du das nicht per Fehlerroutine abgefangen hast und das
Programm nach dem Pack (und einer entsprecehnden Meldung) weiterlaufen
will, knallts.
Ciao
Horst
Norbert
Ernie darf die DBF im Zugriff haben und �nderungen vornehmen! Erst dann
d�rfen alle Mitarbeiter wieder Zugriff auf die ge�nderte DBF haben.
Gel�schte Records d�rfen nicht mehr sichtbar/wiederherstellbar sein! Warum?
Isso!!
"Olaf Doschke" <b2xhZi5kb3NjaGt...@strconv.14.de> schrieb im
Newsbeitrag news:ug$2$aydKH...@TK2MSFTNGP05.phx.gbl...
Norbert
Ernie "h�ngt" ...
open dbf exclusiv
calcthis()
calcthat()
dothis()
dothat()
lpack = IsSomethingdeleted()
if lpack
pack
endif
usi in dbf
Das passiert nicht "immer"! Meistens kommt Stromberg mit seiner Anfrage (dem
ewigen Klicken!) durch und bekommt Zugriff.
Der Fehler tritt nur dann auf, wenn das PACK tats�chlich ausgef�hrt wurde
und der "Zeitpunkt stimmt".
Also nie wenn KEIN Pack ausgef�hrt wurde!
Norbert
"Horst K�hn" <h.k...@freenet.de> schrieb im Newsbeitrag
news:u1pF8dyd...@TK2MSFTNGP02.phx.gbl...
>> Es sei denn, dass bei Ernie in der abschliessenden Routine ein PACK auf
>> die Kunden-DBF ausgef�hrt wird. Dann schmiert Ernies Applikaton, im Falle
tom knauf
also ein C005 nach/bei einem Pack erscheint mir seltsam.
Ich w�rde erstmal die �blichen Verd�chtigen ausschlie�en :
L�schen der Foxuser
Neuaufbau der Indexdateien
Um ganz sicher zu gehen, w�rde ich mal mit Flagdateien arbeiten :
Der erste (der darf) legt "Gesperrt.txt" an, gibt es die Datei, darf keiner
mehr rein, noch bevor Dateien ge�ffnet werden, oder das Programm wird
beendet oder ...
Nach einem PACK oder was auch immer : Datei wieder l�schen.
Ok, beim Absturz muss man die Datei manuell l�schen, aber welches
Foxpro-Programm st�rzt schon ab ? :-)
Man k�nnte nat�rlich statt der Flagdatei auch ein Lock auf eine unkritische
"User.dbf" mit genau 1 Record machen und diesen Lock abfragen
Gr��e
tom
"Norbert" <tii...@gmx.net> schrieb im Newsbeitrag
news:u5G0$3xdKH...@TK2MSFTNGP05.phx.gbl...
Olaf Doschke
> Ernie darf die DBF im Zugriff haben und �nderungen vornehmen!
Dann kann aber Stromberg auch erst nach dem PACK zugriff kriegen,
au�er Foxpro ist so dumm, da� es Stromberg den Zugriff auf die
DBF gibt, die gerade gepackt wird und dabei in eine v�llig neue
Datei umgeschrieben wird. Dann hat Stromberg zugriff auf die
Dateileiche bekommen, die nur noch solange existiert, wie der
PACK l�uft, um die neue Datei zu erstellen, die dann am Schlu� mit
dem alten Namen benannt wird.
L�sung w�re dann wohl, die Retries auf den Zugriff auf die DBF
nicht zu erm�glichen.
Variante2, statt des PACKs lese Dir die komplette DBF in einen
Cursor oder aus Sicherheitsgr�nden in eine tempor�re DBF, dann
ZAP die Tabelle und f�ge die Daten wieder ein. Das ist zeitlich
etwas aufw�ndiger als PACK, geht dann aber wirklich in die
Originaldatei, die Stromberg solange nicht kriegt, bis der Aufr�um-
vorgang wirklich um ist und Ernie die DBF schlie�t.
Tsch��, Olaf.
Norbert
finde es ja wirklich gut wenn sich viele bem�hen und bin ja auch dankbar f�r
die vielen Anregungen, aber ....
- wir haben schon selbst viel ausprobiert
- haben schon selbst Strategien entwickelt, wie man es anders macht
- die �blichen Verd�chtigen ausgeschlossen
- programmieren schon fast 10Jahre VFP
- nehmen jetzt auch die Mehrstunden f�r das "Andersmachen" ungern in kauf
- der Fehler tritt auch nur in einer Cosmos-Umgebung mit vielen hecktischen
Strombergs auf
- der Fehler l��t sich ja auch nachstellen!
Es geht mir um das "Warum ist es so?".
Liegt der Fehler zwischen den Ohren?
Norbert
"Norbert" <tii...@gmx.net> schrieb im Newsbeitrag
news:u5G0$3xdKH...@TK2MSFTNGP05.phx.gbl...
Jürgen Wondzinski
> Info : ist noch VFP7
Dann ist die Sache mit den C0005 klar. VFP7 war sehr bekannt daf�r, dass es
gerne knallt.
a) unbedingt auf VFP9 upgraden.
b) unbedingt die Datei-Logik �berdenken.
Ein PACK innerhalb des normalen Benutzerumfelds, noch dazu im
MultiUser-Betrieb ist ein absolutes No-Go. Da ist die ganze
Verarbeitungs-Denke komplett daneben.
Vorher brauchen wir da garnicht erst weiter machen....
--
wOOdy
Visual FoxPro Technologieberater
Microsoft "Most Valuable Professional" 1996 bis 2009
"*��)
�.���.�*��) �.�*�)
(�.��. (�.�` *
..�`.Visual FoxPro: It's magic !
(�.�``��*
Jürgen Wondzinski
> Ich bin ein fleissiger Newsgroup-Leser und programmieren schon fast
> 10Jahre VFP
Und trotzdem habt ihr noch VFP7 im Einsatz? Krass.
Olaf Doschke
> Liegt der Fehler zwischen den Ohren?
Wie wOOdy eben sagte, liegt der Bug wohl in VFP7, es gibt ja nun eine
Alternative mit VFP9.
Und um meine Vermutung nochmal klar rauszustellen:
W�hrend des PACK gibt es neben dem DBF/CDX/FPT noch drei Tempdateien. Es mag
sein, da� Stromberg schon zu Beginn des PACK zugriff auf die DBF/CDX/FPT
gibt, weil VFP w�hrend des PACK evtl. nur die drei neuen TEMP-Dateien
exklsuiv sch�tzt, die alten Dateien werden ja nur noch gelesen und
ausgenuckelt, umkopiert, am schlu� weggeworfen und durch die neuen Dateien
ersetzt.
Falls dem so w�re, hilft nur, das PACK zu ersetzen, durch Select, ZAP und
Insert oder eben VFP9.
Tsch��, Olaf.
Norbert
Der Druck umzusteigen w�chst sicherlich mit jedem Fehler!
Hier noch einmal mein Extradank f�r die problemnahen Gedanken => DANK�!
Ich werde wohl KOPIEREN, ZAPPEN, INSERTEN und UMBENENNEN => myPack()
( ... oder die Strombergs in die Kaffeek�che schicken!)
Norbert
"Olaf Doschke" <b2xhZi5kb3NjaGt...@strconv.14.de> schrieb im
Newsbeitrag news:%23Yulycz...@TK2MSFTNGP04.phx.gbl...
Olaf Doschke
> ( ... oder die Strombergs in die Kaffeek�che schicken!)
Umbenennen mu�t Du nicht, wenn Du die Original DBF ZAPst
und neu bef�llst, dann ist ja alles darin.
Variante 1:
SET DELETED ON
USE tabelle in 0 EXCLUSIVE && bzw. schon exklusiv ge�ffnet
SELECT * From tabelle INTO CURSOR curTemp nofilter
ZAP IN tabelle
SELECT tabelle
APPEND FROM DBF("curTemp")
USE IN tabelle
USE IN curTemp
Variante 2 (absturzsicher)
SET DELETED ON
USE tabelle in 0 EXCLUSIVE && bzw. schon exklusiv ge�ffnet
CREATE DATABASE dbctemp
COPY tabelle TO tabtemp DATABASE dbctemp
ZAP IN tabelle
SELECT Tabelle
APPEND FROM DBF("tabtemp")
USE IN tabelle
USE IN tabtemp
DROP DATABASE dbctemp DELETETABLES
noch besser: generiere dbc- und tabellennamen mit SYS(2015), damit das sich
nicht in die Quere kommt, wenn es an mehreren Clients liefe oder nach einem
Absturz dbctemp oder tabtemp noch exisitert.
In beiden Varianten landen letztenendes die Daten anders als beim PACK in
exakt der Ursprungsdatei, nicht nur in einer genauso benannten.
In Variante 2 kopierst Du zwar, aber nur tempor�r in eine Tabelle eines
tempor�ren DBC (um features wie lange feldnamen, standardwerte etc. zu
erhalten)
und wenn das Progr�mmchen abst�rzt, hast Du entweder noch in der
Originaltabelle oder in der Kopie davon den kompletten Datenbestand auf
Festplatte. In der Variante 1 besteht direkt nach dem ZAP w�hrend der Insert
l�uft eben die Gefahr, da� bei Absturz etliche Daten futsch sind.
Tsch��, Olaf.
Horst Kühn
Eigentlich ist dazu schon alles gesagt.
> - der Fehler tritt auch nur in einer Cosmos-Umgebung mit vielen hecktischen
> Strombergs auf
> - der Fehler lￜￜt sich ja auch nachstellen!
Dann gï¿œbe es noch eine Mï¿œglichkeit:
- man erzieht Stromberg.
Und da das wahrscheinlich wenig Erfolg hat, kannste ja nach einem
Click den Button erstmal disablen, entsprechende Color oder so - das
keiner das merkt und schon hï¿œrt dieses Miï¿œbrauchen des Buttons als
Schnellfeuerabzug auf. Machts nen kleinen Timer oder wait timeout
"sekï¿œndchen" und schon kehrt Ruhe ein im Gehï¿œuse.
Wenn dann allerdings Stromberg mit dem glï¿œcklichen Hï¿œndchen exakt ini
der richtigen Tausendstel doch clickt, tja...
(Oder legt der nen Backstein auf die Enter Taste?)
- und ne anstï¿œndige Fehlerroutine nï¿œtzt wirklich nix?
> Liegt der Fehler zwischen den Ohren?
Der C0005 weniger.....
Ciao
Horst