| |
 Anzeigen |
|
|
| Social Bookmark Script |
|
|
|
  |
 Harte Nuss |
Roman Köhler 
Administrator
Dabei seit: 29.08.2007
Beiträge: 202
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Mannheim
Betriebssystem: Windows XP
 |
|
Hallo liebe Leuts,
ich habe da mal ne richtig harte Nuss zu knacken.
Grundlage:
Eir haben ein Programm Unternehmen.exe, welches mit verschiedenen übergebenen Workspaces unterschiedliche Datenbestände bearbeitet.
Problem:
In einem Datenbestand funktioniert hängt sich der reread-Befehl auf eine Systemdatei auf und die Verarbeitung kann nicht weiter durchgeführt werden.
Seltsam:
Da in unserem Unternehmensprogramm ca. 220 Views integriert sind und ich nicht ewig auf kopilieren warten wollte, habe ich ein kleines Programm geschrieben, in dem nur die betroffenen Views integriert sind. Und damit gehts problemlos.
Gedanken:
Der Aufruf eines Programmes hängt ja von verschiedenen Faktoren ab: Der exe-Datei, der Workspace, der Filelist und dem dem Datenbestand.
Exe-Datei:
Wäre diese Datei der schuldige Teil, dürften die anderen Datenbestände nicht funktionieren. Andererseits funktioniert mit einer anderen (abgespeckten) exe die Verarbeitung problemlos.
WS-Datei:
Diese Datei wurde mit den Workspaces der funktionierenden Datenbestände verglichen und es wurden keinerlei Fehler festgestellt. Es werden ja auch alle Datendateien richtig geöffnet und gespeichert. Nur bei zwei Geschäftsvorfällen gibt es Probleme.
Filelist.cfg:
Die Einträge der verschiedenen Datenbestände sind absolut identisch.
Datendatei:
Die (nicht funktionierende) Systemdatei wurde durch eine Datendatei aus einem anderen (funktionierenden) Datenbestand ausgetauscht. Doch auch bleibt das Programm beim reread hängen.
Hat irgend jemand eine zündende Idee? Wäre echt klasse.
LG
Roman
|
|
23.07.2008 12:00 |
|
|
Ditte
Foren As
Dabei seit: 23.07.2007
Beiträge: 77
Einsatzart von VDF: gewerblich
Anwenderstatus: Programmierprofi
Herkunft: Berlin
Betriebssystem: XP,Win7,Win Serv2003,2008
|
|
Hallo Roman,
ist wirklich eine harte Nuss.
Wir hatten einen ähnlich Fall. Das Problem würde aber durch Deinen Punkt "Seltsam:" ausgeschlossen.
Trotzdem, vielleicht ein Ansatz.
Während des Schreibens haben wir einen Wert der geschrieben wurde zusammengebaut und vor dem Schreiben geprüft. Dabei haben wir die Abfrage nur auf found aber nicht auf finderr geprüft, so dass er aus der Schleife nicht raus kam. Der Fall trat aber nur sehr selten auf, so dass es schwer war dies zu erkennen.
Kannst Du den Fehler erzeugen?
Vielleich in dem Programm in welchen es passiert Marker setzen die in eine Datei schreiben, damit Du die Werte hast die zu diesem Zeitpunkt geschrieben werden sollen.
Viele Grüsse
__________________
Dittmar
|
|
|
23.07.2008 12:33 |
|
|
Roman Köhler
Administrator
Dabei seit: 29.08.2007
Beiträge: 202
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Mannheim
Betriebssystem: Windows XP
Themenstarter 
|
|
Hallo Dittmar,
die Prozedur, die angestoßen wird, soll einen Counter einer Systemdatei erhöhen. Eine [found] [not found] Abfrage findet vorher nicht statt. Ebenso befinden wir uns in keiner keine Schleife.
Trotzdem danke für Deine Mühe
LG
Roman
|
|
|
23.07.2008 13:22 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
Roman
Für mein Verständnis:
Du hast X Workspaces (.WS), damit Du verschiedene Unternehmensteile separat abdecken kannst (Andere Tabellen/Überschneidende Tabellen etc.). Du hast auch Y .EXE Dateien, die du mit dem jeweils korrekten .WS fütterst.
Zum Problem:
Wenns am Reread scheitert, so liegts meist daran, dass die Datei gesperrt ist (durch einen anderen Reread einer anderen Arbeitsstation oder einer abgeschmierten Session).
Nennen wir die *.DAT mal SYSFILE (Systemdatei, nur 1 Record, der Login-Zähler ist da drin)
Was mir so einfällt:
- Welches SYSFILE.DAT macht er denn wirklich auf (ganzer Pfad) und ist es das SYSFILE.DAT das Du erwartest? Benutze dazu openstat.pkg von VDFQUERY => OpenStat.DisplayFileLocations und zeige Dir den stand nach dem open und vor dem reread an
- Was ist mit den Indizes? (hast wohl keine, oder)
- Was sieht der File-Server, welches SYSFILE.DAT hat er für Dich geöffnet
- Wer hat denn sonst noch (auf dem Server) dieses SYSFILE.DAT offen? (net file auf dem Server)
- Sorge dafür, dass niemand anders SYSFILE.DAT offen hat. Gehts dann? (net file ID /close)
- Was auch noch sein kann: Du hast die Datei 2x innerhalb des EXE offen (als alias)? Einmal mit open und einmal mit open as?
- Benutzt du REREAD oder REREAD SYSFILE ? Wie ist es mit LOCK
- Und: Bist Du sicher, dass es am SYSFILE liegt? Kann es nicht auch eine andere Datei sein. Du könntest z.B. alle offenen Files bis auf SYSFILE auf ReadOnly setzen (set_attribute DF_FILE_MODE of iFile to DF_FILEMODE_READONLY) und erst dann den REREAD durchführen.
HTH, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
23.07.2008 16:41 |
|
|
Roman Köhler
Administrator
Dabei seit: 29.08.2007
Beiträge: 202
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Mannheim
Betriebssystem: Windows XP
Themenstarter
|
|
Hallo Paolo,
die Ausgangssituation ist nahezu so, wie Du sie beschrieben hast:
- ich habe x Workspaces (.ws-files)
- ich habe x Datenbestände
- ich habe nur 1 Programm, welches durch Übergabe einer ws-Datei auf einen der x Datenbestände zugreift.
Die Idee mit der gesperrten Systemdatei kann in diesem Fall nicht sein, da (garantiert) immer nur ein Nutzuer auf diese Datenbestände zugreift.Nun zu Deinen Anregungen:
| Zitat: |
| Welches SYSFILE.DAT macht er denn wirklich auf (ganzer Pfad) und ist es das SYSFILE.DAT, das Du erwartest? Was sieht der File-Server, welches SYSFILE.DAT hat er für Dich geöffnet |
Ich habe auf dem Server nachgeschaut. Es wird wirklich nur die Datei geöffnet, die auch geöffnet werden soll.
| Zitat: |
Was ist mit den Indizes? (hast wohl keine, oder)
|
Nein, weder Idizes noch Komprimierung.
| Zitat: |
Wer hat denn sonst noch (auf dem Server) dieses SYSFILE.DAT offen? (net file auf dem Server)
Sorge dafür, dass niemand anders SYSFILE.DAT offen hat. Gehts dann? (net file ID /close)
|
Niemand, außer mir hat diese Datei geöffnet.
| Zitat: |
Was auch noch sein kann: Du hast die Datei 2x innerhalb des EXE offen (als alias)? Einmal mit open und einmal mit open as?
|
Auch hier ein klares Nein. Die Datei ist definitv nur ein Mal geöffnet. Es existiert kein open as-Eintrag im gesamten Quellcode.
| Zitat: |
Benutzt du REREAD oder REREAD SYSFILE ? Wie ist es mit LOCK?
|
Ich benutze "reread sysfile"
| Zitat: |
Und: Bist Du sicher, dass es am SYSFILE liegt? Kann es nicht auch eine andere Datei sein. Du könntest z.B. alle offenen Files bis auf SYSFILE auf ReadOnly setzen (set_attribute DF_FILE_MODE of iFile to DF_FILEMODE_READONLY) und erst dann den REREAD durchführen.
|
Ich bin mir nahezu 100 %ig sicher. Wenn ich das Programm mit Debugger laufen lasse, und im aufgehängten Zustand auf Pause drücke, springt der Debugger auf die gerade aktuelle Stelle. Und dies ist genau die reread sysfile.Wie gesagt: Verwunderlich ist ja, dass das gleiche Programm ja in den anderen Datenbeständen problemlos funktioniert. Auch dass nach Austausch der nicht funktionierenden Sysfile mit einer aus einem funktionierenden Datenbestand keine Änderung eintritt, finde ich sehr seltsam.Ich bemühe mich gerade die reread-Geschichte durch eine ganz normale Speicherroutine mit request_save zu ersetzen. Bin also voller Hoffnung, dass ich mit diesem Workaround mein Problem in den Griff bekomme; aber verstehen tu ich's trotzdem nicht.Vielen herzlichen Dank für Deine Mühe.LGRoman
(und warum sind jetzt meine ganzen Zeilenumbrüche weg?)
|
|
|
24.07.2008 13:25 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
Roman
Ja, die Nuss ist hart..
Viel fällt mir nun nicht mehr ein:
- Berechtigungen auf dem Fileserver? (vielleicht mal alle User alle Rechte setzen)
- Die SYSFILE Neu erstellen: Zuerst SYSFILE.* (DAT, FD, TAG, HDR, K*) löschen und dann aus dem DEF neu erstellen und mit den korrekten Daten füllen.
HTH, ziemlich ratloser Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
24.07.2008 14:23 |
|
|
Roman Köhler
Administrator
Dabei seit: 29.08.2007
Beiträge: 202
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Mannheim
Betriebssystem: Windows XP
Themenstarter
|
|
Hallo Dittmar, hallo Paolo, und Ihr alle da draußen,
ICH HABS GEFUNDEN
Um die Lösung zu erfahren, müsst Ihr aber leider meinen geistigen Ergüssen noch etwas folgen:
Da sich das gleiche Programm (exe) mit einer unterschiedlichen, aber garantiert richtigen Workspace-Datei (ws) und mit unterschiedlichen Datenbeständen unterschiedlich verhielt, tauschte ich zuerst das nicht funktionierende Datenverzeichnis gegen ein funktionierendes aus. Damit klappte es. Also konnte es sich nicht (wie vermutet) am Programm und an der ws-Datei liegen. Alles wieder zurück und succesive den Inhalt der Datenverzeichnisses ausgetauscht. Und siehe da:
Es war die Filelist.cfg
Bei einer Aktualisierung der eigentlich identischen Filelists gab ich bei einer Filelist eine Datendatei doppelt ein. File 231 und 232 verwiesen auf die gleiche Datei. Diese hatte zwar mit dem aktuellen Speichervorgang gar nichts zu tun, aber ein expliziter reread führt hier zu einem Deadlock. Die normalen request_save-Prozeduren scheinen da anders zu arbeiten, sonst hätte ich ja keinen einzigen Datensatz mehr neu anlegen, speichern oder löschen können. Abder in diesem Fall wurde halt nun mal mit reread und unlock gearbeitet.
So, lag der Fehler also wieder einmal beim (doofen) Anwender.
Vielen Dank für Eure Mühe
und vielleicht erinnert Ihr Euch ja mal an dieses Problem, wenn ich auch mal einen Eingabefehler in der Filelist macht.
LG
Roman
|
|
|
24.07.2008 16:45 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
EiEiEi
Dataflex ist immer für Ueberraschungen gut.
FYI
Die Request_Save Prozedur, die auf eine DDO Struktur losgelassen wird, lockt nur die in der Struktur benutzten Tables. Das macht das System indem die nicht-benutzten Tabellen auf DF_FILE_READONLY gesetzt werden. Erst danach kommt der ReRead/Lock.
Dieser Mechanismus sogt dafür, dass also die anderen x Tabellen nicht gelockt werden und somit die anderen Benutzer die auf andere Tabellen speichern nicht warten müssen, bis die meine Transaktion durch ist. Das ist von grossem Vorteil, wenn mit der 'Embedded' Datenbank gearbeitet wird.
Gruss, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
24.07.2008 17:02 |
|
|
Ditte
Foren As
Dabei seit: 23.07.2007
Beiträge: 77
Einsatzart von VDF: gewerblich
Anwenderstatus: Programmierprofi
Herkunft: Berlin
Betriebssystem: XP,Win7,Win Serv2003,2008
|
|
Hi Roman,
darauf muss man erst einmal kommen.
Glückwunsch.
__________________
Dittmar
|
|
|
24.07.2008 17:38 |
|
|
Danka
Mitglied
Dabei seit: 27.12.2007
Beiträge: 27
|
|
Hallo Roman,
habe mir heute deinen Beitrag durchgelesen. In der Tat, da muss man erst drauf kommen. Dein Beitrag hat mich interessiert, weil auch bei mir der REREAD "hängt", und zwar überall wo ich auf den Dateibuffer zugreifen will.
Als ich meine Views entwickelt habe, hat noch alles funktioniert und seit einer Weile (könnten 2 Wochen sein) bleiben Views mit einem REREAD "hängen".
Nun, in meiner Filelist hab ich seit 2 Wochen aber durchaus doppelte Dateieinträge und zwar für die Alias. Bei einem Alia beziehe ich mich doch immer auf das gleiche Filename und unterscheide diese durch unterschiedliche Tablenames?
Hab ich da jetzt bei deiner Lösung was falsch verstanden? Geht nur das eine oder das andere?
Gruß Danka
|
|
|
23.06.2009 11:40 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
Hallo Danka
Die Alias Files greifen auf dieselben physischen Tabellen wie die Master zu (.DAT). Da Dataflex mit der embedded Datenbank die ganze Table lockt (also das file) kann das beim Alias nicht mehr gehen resp. es wartet bis es frei wird.
Bei alias Files musst Du den DF_File_Mode korrekt setzen (Es gibt einen speziellen Modus für Alias Tables).
==> Schau in der Hilfe nach und suche nach "Alias Tables" - dort ist zumindest die Integration von Alias Files in eine DD Struktur erklärt.
Gruss, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
23.06.2009 12:14 |
|
|
Danka
Mitglied
Dabei seit: 27.12.2007
Beiträge: 27
|
|
Hallo Paolo,
vielen Dank für die schnelle Antwort.
Das DF_Attribute DF_FILE_Alias ist soweit ich es sehen kann korrekt gesetzt. Alias-Dateien werden laut Hilfe gleich behandelt wie Read-Only-Dateien. Hab aber noch zusätzlich den File_Mode auf Read_Only gesetzt, leider ohne Erfolg.
Somit steht in der Master-Datei:
Set_Attribute DF_FILE_ALIAS Of VKAUFP.File_Number to DF_FILE_IS_MASTER
Class Vkaufp_DataDictionary is a DataDictionary
...
und in der Alias:
Set_Relate VKAUFP_A.VKAUFK_nummer to |FN0,0
Set_Relate VKAUFP_A.Prod_staette to |FN0,0
Set_Attribute DF_FILE_MODE Of VKAUFP_A.File_Number To DF_FILEMODE_READONLY
Set_Attribute DF_FILE_ALIAS Of VKAUFP_A.File_Number to DF_FILE_IS_ALIAS
Class Vkaufp_A_DataDictionary is a DataDictionary
...
Habe nur gehofft, dass Romans Eintrag irgendwas mit meinem Problem gemeinsam hat. Oder kannst du auf dem ersten Blick einen Denkfehler entdecken. Die Alias funktionieren eigentlich wunderbar.
Gruss Danka
|
|
|
23.06.2009 13:05 |
|
|
abraxas
Doppel-As
Dabei seit: 23.07.2007
Beiträge: 107
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Frauenfeld (CH)
|
|
Danka
Und wenn es Du gemäss Hilfe machst (die Definition erfolgt dabei komplett in der ALIAS DD)
Also NUR im ALIAS DD das Master DD bleibt 'standard':
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
|
open VKAUFP
Set_Attribute DF_FILE_ALIAS VKAUFP_A.File_Number to DF_FILE_IS_ALIAS
Set_Attribute DF_FILE_ALIAS VKAUFP.File_Number to DF_FILE_IS_MASTER
Set_Relate VKAUFP_A.VKAUFK_nummer to |FN0,0
Set_Relate VKAUFP_A.Prod_staette to |FN0,0
Class Vkaufp_A_DataDictionary is a DataDictionary
... |
|
Greifst Du denn überhaupt via DD zu, oder machst Du das manuell mit 'ReRead'/'Unlock' etc?
Du könntest auch die Attribute vor dem ReRead anzeigen lassen. Vllt ist es ja eine ganz andere Tabelle. Du kannst dazu VDFQUERY benutzen. Baue das ein und rufe die Methode wenn angebracht auf. Irgendwo wird das file "openstat.txt" erstellt.
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
|
Use openstat.pkg
Procedure DoDump Global
Handle hoOpen
Get create U_cTablesOpenStatus to hoOpen
Send RegisterCurrentOpenFiles of hoOpen
Send write_file of hoOpen
Send Destroy of hoOpen
End_Procedure |
|
HTH, Paolo
__________________
=================
Abraxas Informatik AG
Schweiz
=================
|
|
|
23.06.2009 14:21 |
|
|
Danka
Mitglied
Dabei seit: 27.12.2007
Beiträge: 27
|
|
Hallo Paolo,
1. habe beides gemacht; zunächst den Code nur in Alias rein und master auf standard - keine Änderung.
2. in der openstat.txt stehen alle Dateien und alias mit 0 drin, hab die Prozedur vor dem reread aufgerufen.
Normalerweise arbeite ich schon über DD und die entsprechenden Befehle. An manchen Stellen hab ich jedoch einen manuellen Eingriff über Reread/Saverecord/Unlock, und genau da geht es nicht weiter, aber eben erst seit einer Weile.
Hab aber ein TestProjekt angelegt, diesem ein vorhandenes View zugeordnet, die Alias entfernt und siehe da, View funktioniert wieder.
Jetzt mach ich es mal der Reihe nach für jede Alia-Datei, mal schauen ob es eine einzelne ist und wo mein Fehler ist.
Werde berichten.
Gruß
|
|
|
24.06.2009 16:47 |
|
|
Danka
Mitglied
Dabei seit: 27.12.2007
Beiträge: 27
|
|
Also,
ich habe noch nicht ganz kappiert, aber wenn ich Alias-Tabellen, die als Add_Client_File in relationierten DDs hinterlegt sind, auskommentiere, dann hängt meine View nicht mehr.
Im Relationenreport wird das dann natürlich als Warnung angezeigt.
dabei lösch ich doch die Relationen in den Alias mit dem Befehl:
Set_Relate File.Field to |FN0,0.
bin für jeden Tipp dankbar, suche weiter...
Grüße
|
|
|
24.06.2009 17:16 |
|
|
Matthias
Super Moderator
Dabei seit: 09.07.2007
Beiträge: 233
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Niedernhausen
Betriebssystem: XP, Vista, Win7, 2008 Ser
|
|
Beigefügtes kleines Tool hat mir sofort geholfen, als ich die Datenbank von Pervasive.SQL auf MySQL (C-ISAM) umgestellt hatte und ebenfalls LOCK-Probleme hatte.
Matthias
|
|
|
26.06.2009 09:32 |
|
|
Danka
Mitglied
Dabei seit: 27.12.2007
Beiträge: 27
|
|
Halo Matthias,
vielen Dank für das Tool, es hat mir insoweit geholfen, dass ich jetzt weiß, dass mit meinen Alias irgendetwas nicht stimmt. Die Mastertabellen werden als geöffnet und mit "master" gekennzeichnet angezeigt, die Alias dagegen als nicht geöffnet und mit "?????".
Das würde ja bedeuten, dass das Attribut DF_FILE_ALIAS nicht auf DF_FILE_IS_ALIA gesetzt ist...hmmm, wenn das nur so einfach wäre, das Attribut ist nämlich gesetzt wie z.B. bei:
Set_Attribute DF_FILE_ALIAS of ART_A.File_Number to DF_FILE_IS_ALIAS
Class Art_A_DataDictionary is a DataDictionary
...
In der Master steht dann:
Set_Attribute DF_FILE_ALIAS Of ART.File_Number to DF_FILE_IS_MASTER
Class Art_DataDictionary is a DataDictionary
...
Verwirrend find ich zwar, dass in der Hilfe und unter DAW unterschiedliche Aussagen darüber existieren, wo der Master definiert werden soll, in der Mastertabelle oder in der Alias. Ich hab es jetzt in der Master stehen, dann wird auch in deinem Tool die Tabelle als Master angezeigt. Steht Master und Alias in der Aliastabelle, so wird im Tool auch die Mastertabelle als nicht geöffnet und ohne Masterkennzeichnung angezeigt.
Ich weiß nicht, ob ich vor lauter Bäume den Wald nicht mehr sehe aber das Attribut ist doch gesetzt, wieso werden dann die Alias nicht erkannt?
LG
Danka
|
|
|
26.06.2009 14:42 |
|
|
Matthias
Super Moderator
Dabei seit: 09.07.2007
Beiträge: 233
Einsatzart von VDF: gewerblich
Anwenderstatus: VDF-Entwickler
Herkunft: Niedernhausen
Betriebssystem: XP, Vista, Win7, 2008 Ser
|
|
Ich habe grundsätzlich in BEIDEN Data Dictionary die entsprechenden Optionen gesetzt:
Open STOFF
Open STOFF2
Set_Attribute DF_FILE_ALIAS of STOFF.File_Number to DF_FILE_IS_MASTER
Set_Attribute DF_FILE_ALIAS of STOFF2.File_Number to DF_FILE_IS_ALIAS
Ein doppeltes Öffenen einer Datei tut nichts zur Sache. Aber so ist sichergestellt, dass bei beiden DDs die FileModes gesetzt sind.
Viele Grüße
Matthias
|
|
|
30.06.2009 12:04 |
|
|
Danka
Mitglied
Dabei seit: 27.12.2007
Beiträge: 27
|
|
Halo Matthias,
habe das Problem einige Tage ruhen lassen.
Aber du hattest Recht, habe jetzt auch in beiden DDs Alias und Master Zuordnung eingetragen und siehe da.... ES FUNKTIONIERT!
Habe dann auch noch spasseshalber die Zuordnungen in ALIAS rausgenommen und auch da funktionierts. Habe sie zwar wieder eingetragen, das würde aber bedeuten, dass die Zuordnungen in den Master-DDs ausschlaggebend sind.
Tja nun, sei es drum :o)
Vielen Dank für die Unterstützung, dein Tool war hier sehr hilfreich!
Jetzt tut es mir nur leid, dass ein Alias-Problem in einem ganz anderem Beitrag behandelt wurde, wusste aber ursprünglich nicht, dass es sich in diese Richtung entwickelt.
Nochmals Danke,
viele Grüße
Danka
|
|
|
14.07.2009 10:54 |
|
|
|
|
|
|
|
GELÖST: Harte Nuss