Kein Mobilfunknetz auf iPhone nach Update auf iOS 7

23. September 2013 Posted by Manfred Meise

Am 18. September veröffentlichte Apple die neueste Generaion iOS7. Nach einem (einigermaßen zeitaufwendigen) sofortigen Update muss man sich erst einmal mit der neuen Oberfläche (Funktionen sind an andere Stellen gewandert, Gestensteuerung erweitert und verändert, u.s.w.) gewöhnen. Viel schlimmer war, dass die Telefonie nicht merh funktionierte: "Kein Netz". Alle Hinweise im Netz zur Überprüfung der Netzbetreibereinstellungen halfen nicht weiter. Ausschalten / Einschalten (oftmals hilfreiche Schritte mit wenig Aufwand) brachte ebensfalls die GSM Verbindung nicht zurück. Besonders stutzig machten mich bei manueller Auswahl meines Netzanbieters der Hinweis "Einschränkungen verfügbar.....". Nach Blick in "Einstellungen - Allgemein - Info - Netzwerk" erhielt ich den Hinweis "Sim nicht zulässig".

Als letzten Versuch vor dem Anruf beim Telefonnetzanbieter habe ich dann einmal ein vollständiges Reset des Gerätes mit "Gleichzeitiges Drücken des Ausschaltknopfes und der Home-Taste" versucht. Und siehe da: Nach dem erneuten Start des Telefons loggt sich mein Telefon wieder ungehindert ins Netz ein und ich kann wieder telefonieren!
Read full article |Kommentare deaktiviert für Kein Mobilfunknetz auf iPhone nach Update auf iOS 7
Tags:
Categories: Allgemein

Kein Mobilfunknetz auf iPhone nach Update auf iOS 7

23. September 2013 Posted by Manfred Meise

Am 18. September veröffentlichte Apple die neueste Generaion iOS7. Nach einem (einigermaßen zeitaufwendigen) sofortigen Update muss man sich erst einmal mit der neuen Oberfläche (Funktionen sind an andere Stellen gewandert, Gestensteuerung erweitert und verändert, u.s.w.) gewöhnen. Viel schlimmer war, dass die Telefonie nicht merh funktionierte: "Kein Netz". Alle Hinweise im Netz zur Überprüfung der Netzbetreibereinstellungen halfen nicht weiter. Ausschalten / Einschalten (oftmals hilfreiche Schritte mit wenig Aufwand) brachte ebensfalls die GSM Verbindung nicht zurück. Besonders stutzig machten mich bei manueller Auswahl meines Netzanbieters der Hinweis "Einschränkungen verfügbar.....". Nach Blick in "Einstellungen - Allgemein - Info - Netzwerk" erhielt ich den Hinweis "Sim nicht zulässig".

Als letzten Versuch vor dem Anruf beim Telefonnetzanbieter habe ich dann einmal ein vollständiges Reset des Gerätes mit "Gleichzeitiges Drücken des Ausschaltknopfes und der Home-Taste" versucht. Und siehe da: Nach dem erneuten Start des Telefons loggt sich mein Telefon wieder ungehindert ins Netz ein und ich kann wieder telefonieren!
Read full article |Kommentare deaktiviert für Kein Mobilfunknetz auf iPhone nach Update auf iOS 7
Tags:
Categories: Allgemein

Kein Mobilfunknetz auf iPhone nach Update auf iOS 7

23. September 2013 Posted by Manfred Meise

Am 18. September veröffentlichte Apple die neueste Generaion iOS7. Nach einem (einigermaßen zeitaufwendigen) sofortigen Update muss man sich erst einmal mit der neuen Oberfläche (Funktionen sind an andere Stellen gewandert, Gestensteuerung erweitert und verändert, u.s.w.) gewöhnen. Viel schlimmer war, dass die Telefonie nicht merh funktionierte: "Kein Netz". Alle Hinweise im Netz zur Überprüfung der Netzbetreibereinstellungen halfen nicht weiter. Ausschalten / Einschalten (oftmals hilfreiche Schritte mit wenig Aufwand) brachte ebensfalls die GSM Verbindung nicht zurück. Besonders stutzig machten mich bei manueller Auswahl meines Netzanbieters der Hinweis "Einschränkungen verfügbar.....". Nach Blick in "Einstellungen - Allgemein - Info - Netzwerk" erhielt ich den Hinweis "Sim nicht zulässig".

Als letzten Versuch vor dem Anruf beim Telefonnetzanbieter habe ich dann einmal ein vollständiges Reset des Gerätes mit "Gleichzeitiges Drücken des Ausschaltknopfes und der Home-Taste" versucht. Und siehe da: Nach dem erneuten Start des Telefons loggt sich mein Telefon wieder ungehindert ins Netz ein und ich kann wieder telefonieren!
Read full article |Kommentare deaktiviert für Kein Mobilfunknetz auf iPhone nach Update auf iOS 7
Tags:
Categories: Allgemein

Kein Mobilfunknetz auf iPhone nach Update auf iOS 7

23. September 2013 Posted by Manfred Meise

Am 18. September veröffentlichte Apple die neueste Generaion iOS7. Nach einem (einigermaßen zeitaufwendigen) sofortigen Update muss man sich erst einmal mit der neuen Oberfläche (Funktionen sind an andere Stellen gewandert, Gestensteuerung erweitert und verändert, u.s.w.) gewöhnen. Viel schlimmer war, dass die Telefonie nicht merh funktionierte: "Kein Netz". Alle Hinweise im Netz zur Überprüfung der Netzbetreibereinstellungen halfen nicht weiter. Ausschalten / Einschalten (oftmals hilfreiche Schritte mit wenig Aufwand) brachte ebensfalls die GSM Verbindung nicht zurück. Besonders stutzig machten mich bei manueller Auswahl meines Netzanbieters der Hinweis "Einschränkungen verfügbar.....". Nach Blick in "Einstellungen - Allgemein - Info - Netzwerk" erhielt ich den Hinweis "Sim nicht zulässig".

Als letzten Versuch vor dem Anruf beim Telefonnetzanbieter habe ich dann einmal ein vollständiges Reset des Gerätes mit "Gleichzeitiges Drücken des Ausschaltknopfes und der Home-Taste" versucht. Und siehe da: Nach dem erneuten Start des Telefons loggt sich mein Telefon wieder ungehindert ins Netz ein und ich kann wieder telefonieren!
Read full article |Kommentare deaktiviert für Kein Mobilfunknetz auf iPhone nach Update auf iOS 7
Tags:
Categories: Allgemein

Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgefĂĽhrt

6. Juni 2013 Posted by Manfred Meise

Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien fĂĽr LotusScript-Klassen
  • Verwendung von abgeleiteten Klassen
  • Umfangreiche Fehlerbehandlung in allen Methoden
  • Verwendung von Codeschablonen im Domino Designer fĂĽr Eclipse (DDE)

So musste ich jĂĽngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgefĂĽhrt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgefĂĽhrt wird. 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               MessageBox "BaseClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "BaseClass",,"Delete" 
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
               MessageBox "DerivedClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "DerivedClass",,"Delete" 
       End Sub 
       
 End Class


So sollte z.B. folgender Code 
 
 Public Sub CreateClass 
       
       Set currentClass = New DerivedClass (1)         
       Delete currentClass 
       
 End Sub

Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.

Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"New" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"Delete" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
       
               On Error GoTo ErrorBubble 
       
               MessageBox "DerivedClass",,"New" 
       
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
 
               On Error GoTo ErrorBubble 
 
               MessageBox "DerivedClass",,"Delete" 
 
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class


Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Read full article |Kommentare deaktiviert für Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgefĂĽhrt
Tags:
Categories: Allgemein

Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgefĂĽhrt

6. Juni 2013 Posted by Manfred Meise

Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien fĂĽr LotusScript-Klassen
  • Verwendung von abgeleiteten Klassen
  • Umfangreiche Fehlerbehandlung in allen Methoden
  • Verwendung von Codeschablonen im Domino Designer fĂĽr Eclipse (DDE)

So musste ich jĂĽngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgefĂĽhrt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgefĂĽhrt wird. 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               MessageBox "BaseClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "BaseClass",,"Delete" 
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
               MessageBox "DerivedClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "DerivedClass",,"Delete" 
       End Sub 
       
 End Class


So sollte z.B. folgender Code 
 
 Public Sub CreateClass 
       
       Set currentClass = New DerivedClass (1)         
       Delete currentClass 
       
 End Sub

Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.

Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"New" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"Delete" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
       
               On Error GoTo ErrorBubble 
       
               MessageBox "DerivedClass",,"New" 
       
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
 
               On Error GoTo ErrorBubble 
 
               MessageBox "DerivedClass",,"Delete" 
 
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class


Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Read full article |Kommentare deaktiviert für Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgefĂĽhrt
Tags:
Categories: Allgemein

Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt

6. Juni 2013 Posted by Manfred Meise

Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien für LotusScript-Klassen
  • Verwendung von abgeleiteten Klassen
  • Umfangreiche Fehlerbehandlung in allen Methoden
  • Verwendung von Codeschablonen im Domino Designer für Eclipse (DDE)

So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird. 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               MessageBox "BaseClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "BaseClass",,"Delete" 
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
               MessageBox "DerivedClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "DerivedClass",,"Delete" 
       End Sub 
       
 End Class


So sollte z.B. folgender Code 
 
 Public Sub CreateClass 
       
       Set currentClass = New DerivedClass (1)         
       Delete currentClass 
       
 End Sub

Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.

Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"New" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"Delete" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
       
               On Error GoTo ErrorBubble 
       
               MessageBox "DerivedClass",,"New" 
       
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
 
               On Error GoTo ErrorBubble 
 
               MessageBox "DerivedClass",,"Delete" 
 
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class


Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Read full article |Kommentare deaktiviert für Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt
Tags:
Categories: Allgemein

Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt

6. Juni 2013 Posted by Manfred Meise

Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien für LotusScript-Klassen
  • Verwendung von abgeleiteten Klassen
  • Umfangreiche Fehlerbehandlung in allen Methoden
  • Verwendung von Codeschablonen im Domino Designer für Eclipse (DDE)

So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird. 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               MessageBox "BaseClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "BaseClass",,"Delete" 
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
               MessageBox "DerivedClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "DerivedClass",,"Delete" 
       End Sub 
       
 End Class


So sollte z.B. folgender Code 
 
 Public Sub CreateClass 
       
       Set currentClass = New DerivedClass (1)         
       Delete currentClass 
       
 End Sub

Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.

Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"New" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"Delete" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
       
               On Error GoTo ErrorBubble 
       
               MessageBox "DerivedClass",,"New" 
       
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
 
               On Error GoTo ErrorBubble 
 
               MessageBox "DerivedClass",,"Delete" 
 
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class


Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Read full article |Kommentare deaktiviert für Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt
Tags:
Categories: Allgemein

Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt

6. Juni 2013 Posted by Manfred Meise

Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien für LotusScript-Klassen
  • Verwendung von abgeleiteten Klassen
  • Umfangreiche Fehlerbehandlung in allen Methoden
  • Verwendung von Codeschablonen im Domino Designer für Eclipse (DDE)

So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird. 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               MessageBox "BaseClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "BaseClass",,"Delete" 
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
               MessageBox "DerivedClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "DerivedClass",,"Delete" 
       End Sub 
       
 End Class


So sollte z.B. folgender Code 
 
 Public Sub CreateClass 
       
       Set currentClass = New DerivedClass (1)         
       Delete currentClass 
       
 End Sub

Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.

Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"New" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"Delete" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
       
               On Error GoTo ErrorBubble 
       
               MessageBox "DerivedClass",,"New" 
       
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
 
               On Error GoTo ErrorBubble 
 
               MessageBox "DerivedClass",,"Delete" 
 
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class


Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Read full article |Kommentare deaktiviert für Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt
Tags:
Categories: Allgemein

Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt

6. Juni 2013 Posted by Manfred Meise

Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien für LotusScript-Klassen
  • Verwendung von abgeleiteten Klassen
  • Umfangreiche Fehlerbehandlung in allen Methoden
  • Verwendung von Codeschablonen im Domino Designer für Eclipse (DDE)

So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird. 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               MessageBox "BaseClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "BaseClass",,"Delete" 
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
               MessageBox "DerivedClass",,"New" 
       End Sub 
       
       Sub Delete 
               MessageBox "DerivedClass",,"Delete" 
       End Sub 
       
 End Class


So sollte z.B. folgender Code 
 
 Public Sub CreateClass 
       
       Set currentClass = New DerivedClass (1)         
       Delete currentClass 
       
 End Sub

Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.

Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code 

 
 Class BaseClass 
               
       Public Status As String 
       
       Public Sub new (intNumber As Integer) 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"New" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
               
               On Error GoTo ErrorBubble 
               
               MessageBox "BaseClass",,"Delete" 
               
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class 
 
 Class DerivedClass As BaseClass 
       
       Public Sub New (intNumber As Integer), BaseClass (intNumber) 
       
               On Error GoTo ErrorBubble 
       
               MessageBox "DerivedClass",,"New" 
       
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
       Sub Delete 
 
               On Error GoTo ErrorBubble 
 
               MessageBox "DerivedClass",,"Delete" 
 
 SingleExit: 
               Exit Sub 
               
               '......................................................................................................         
 ErrorBubble:         
               Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) &  { : } & Erl         
               
               Resume SingleExit 
               
       End Sub 
       
 End Class


Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Read full article |Kommentare deaktiviert für Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt
Tags:
Categories: Allgemein

Heise.de: Lotus Notes mit riesigem Java-Loch! – Ich verstehe die Aufregung nicht!

3. Mai 2013 Posted by Manfred Meise

Seitdem gestern auf heise.de von einem riesigen Java-Loch berichtet wurde, sind Administratoren unserer Kunden verunsichert und entwickeln ungewohnten Aktionismus. Besondern gern wird in Erwägung gezogen, die in der Meldung genannten Notes.ini Parameter 

 
 EnableJavaApplets=0
 EnableLiveConnect=0
 EnableJavaScript=0


zu setzen, ohne zu wissen, welche Client Funktionen sie damit blocken oder welche Anwendungen anschließend nicht mehr funktionieren.

Führt man den entsprechenden Heise.de Mailcheck für Java aus, erhält man eine entsprechende Testmail, um zu prüfen, ob die Lotus Notes Clients unsignierten Code ausführen. Ich bin dabei sehr entspannt, denn in Fällen wo wir aktiv die ECLs der Lotus Notes Notes Clients bei uns und unseren Kunden (über Desktop-Richtlinien) konzipiert und kontrolliert haben, schützen diese die Lotus Notes Clients von Haus aus. Hierbei ist es wichtig, Keine Aktionen für unsignierten (und noch besser: auch für "-Default-" Signaturen) Code nicht auszuführen. Hat man obendrein auch dem Benutzer das Recht entzogen selbst Vertrauensstellungen auszusprechen, muss ich eigentlich keine Panik haben.
Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Darüber hinaus könnten Administratoren auch explizit die Applet-Security in Desktop-Richtlinien spezifisch steuern:

Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Also: Keine Panik, aber bitte auch nicht einfach an ECLs und Richtlinien "schrauben", ohne die Auswirkungen abschätzen zu können.

Read full article |Kommentare deaktiviert für Heise.de: Lotus Notes mit riesigem Java-Loch! – Ich verstehe die Aufregung nicht!
Tags:
Categories: Allgemein

Heise.de: Lotus Notes mit riesigem Java-Loch! – Ich verstehe die Aufregung nicht!

3. Mai 2013 Posted by Manfred Meise

Seitdem gestern auf heise.de von einem riesigen Java-Loch berichtet wurde, sind Administratoren unserer Kunden verunsichert und entwickeln ungewohnten Aktionismus. Besondern gern wird in Erwägung gezogen, die in der Meldung genannten Notes.ini Parameter 

 
 EnableJavaApplets=0
 EnableLiveConnect=0
 EnableJavaScript=0


zu setzen, ohne zu wissen, welche Client Funktionen sie damit blocken oder welche Anwendungen anschließend nicht mehr funktionieren.

Führt man den entsprechenden Heise.de Mailcheck für Java aus, erhält man eine entsprechende Testmail, um zu prüfen, ob die Lotus Notes Clients unsignierten Code ausführen. Ich bin dabei sehr entspannt, denn in Fällen wo wir aktiv die ECLs der Lotus Notes Notes Clients bei uns und unseren Kunden (über Desktop-Richtlinien) konzipiert und kontrolliert haben, schützen diese die Lotus Notes Clients von Haus aus. Hierbei ist es wichtig, Keine Aktionen für unsignierten (und noch besser: auch für "-Default-" Signaturen) Code nicht auszuführen. Hat man obendrein auch dem Benutzer das Recht entzogen selbst Vertrauensstellungen auszusprechen, muss ich eigentlich keine Panik haben.
Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Darüber hinaus könnten Administratoren auch explizit die Applet-Security in Desktop-Richtlinien spezifisch steuern:

Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Also: Keine Panik, aber bitte auch nicht einfach an ECLs und Richtlinien "schrauben", ohne die Auswirkungen abschätzen zu können.

Read full article |Kommentare deaktiviert für Heise.de: Lotus Notes mit riesigem Java-Loch! – Ich verstehe die Aufregung nicht!
Tags:
Categories: Allgemein

Heise.de: Lotus Notes mit riesigem Java-Loch! – Ich verstehe die Aufregung nicht!

3. Mai 2013 Posted by Manfred Meise

Seitdem gestern auf heise.de von einem riesigen Java-Loch berichtet wurde, sind Administratoren unserer Kunden verunsichert und entwickeln ungewohnten Aktionismus. Besondern gern wird in Erwägung gezogen, die in der Meldung genannten Notes.ini Parameter 

 
 EnableJavaApplets=0
 EnableLiveConnect=0
 EnableJavaScript=0


zu setzen, ohne zu wissen, welche Client Funktionen sie damit blocken oder welche Anwendungen anschließend nicht mehr funktionieren.

Führt man den entsprechenden Heise.de Mailcheck für Java aus, erhält man eine entsprechende Testmail, um zu prüfen, ob die Lotus Notes Clients unsignierten Code ausführen. Ich bin dabei sehr entspannt, denn in Fällen wo wir aktiv die ECLs der Lotus Notes Notes Clients bei uns und unseren Kunden (über Desktop-Richtlinien) konzipiert und kontrolliert haben, schützen diese die Lotus Notes Clients von Haus aus. Hierbei ist es wichtig, Keine Aktionen für unsignierten (und noch besser: auch für "-Default-" Signaturen) Code nicht auszuführen. Hat man obendrein auch dem Benutzer das Recht entzogen selbst Vertrauensstellungen auszusprechen, muss ich eigentlich keine Panik haben.
Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Darüber hinaus könnten Administratoren auch explizit die Applet-Security in Desktop-Richtlinien spezifisch steuern:

Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Also: Keine Panik, aber bitte auch nicht einfach an ECLs und Richtlinien "schrauben", ohne die Auswirkungen abschätzen zu können.

Read full article |Kommentare deaktiviert für Heise.de: Lotus Notes mit riesigem Java-Loch! – Ich verstehe die Aufregung nicht!
Tags:
Categories: Allgemein

Heise.de: Lotus Notes mit riesigem Java-Loch! – Ich verstehe die Aufregung nicht!

3. Mai 2013 Posted by Manfred Meise

Seitdem gestern auf heise.de von einem riesigen Java-Loch berichtet wurde, sind Administratoren unserer Kunden verunsichert und entwickeln ungewohnten Aktionismus. Besondern gern wird in Erwägung gezogen, die in der Meldung genannten Notes.ini Parameter 

 
 EnableJavaApplets=0
 EnableLiveConnect=0
 EnableJavaScript=0


zu setzen, ohne zu wissen, welche Client Funktionen sie damit blocken oder welche Anwendungen anschlieĂźend nicht mehr funktionieren.

Führt man den entsprechenden Heise.de Mailcheck für Java aus, erhält man eine entsprechende Testmail, um zu prüfen, ob die Lotus Notes Clients unsignierten Code ausführen. Ich bin dabei sehr entspannt, denn in Fällen wo wir aktiv die ECLs der Lotus Notes Notes Clients bei uns und unseren Kunden (über Desktop-Richtlinien) konzipiert und kontrolliert haben, schützen diese die Lotus Notes Clients von Haus aus. Hierbei ist es wichtig, Keine Aktionen für unsignierten (und noch besser: auch für "-Default-" Signaturen) Code nicht auszuführen. Hat man obendrein auch dem Benutzer das Recht entzogen selbst Vertrauensstellungen auszusprechen, muss ich eigentlich keine Panik haben.
Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Darüber hinaus könnten Administratoren auch explizit die Applet-Security in Desktop-Richtlinien spezifisch steuern:

Image:Heise.de: Lotus Notes mit riesigem Java-Loch! - Ich verstehe die Aufregung nicht!

Also: Keine Panik, aber bitte auch nicht einfach an ECLs und Richtlinien "schrauben", ohne die Auswirkungen abschätzen zu können.

Read full article |Kommentare deaktiviert für Heise.de: Lotus Notes mit riesigem Java-Loch! – Ich verstehe die Aufregung nicht!
Tags:
Categories: Allgemein

Gelöschte Benutzer wieder reaktivieren

30. April 2013 Posted by Manfred Meise

Im Verlauf des "Lebenszyklus" eines Domino Benutzer ist klar, dass dieser nicht nur irgendwann neu angelegt wird, sondern möglicherweise auch einmal gelöscht/deaktiviert werden will. In seltenen Fällen sollen anschließend die gelöschten/deaktivierten Benutzer wieder reaktiviert werden und möglichst unverändert so weiter arbeiten wie zuletzt. Abhängig davon, wie die Benutzer zuvor gelöscht/deaktiviert worden sind, mag sich dieses jedoch schwierig gestalten:

Domino Administratoren können mit Hilfe des Domino Administrator Clients Benutzer löschen und hierbei entscheiden,
  • was mit dem Mailfile (sowie ggf. Den Roaming Files) des Benutzers geschehen soll
  • wie die Benutzer-ID des Benutzers im Vault behandelt werden soll
  • ob der Benutzer in eine Negativgruppe aufgenommen werden soll, um ihm die Zugriffberechtigungen auf sämtliche Server zu entziehen

Auf jeden Fall wird durch diesen Vorgang das Personendokument gelöscht.

Diese "Bordmittel" werfen dann mehr oder weniger große Fragen und Probleme auf, wenn der Benutzer nach einiger Zeit doch wieder "reaktiviert" werden soll (z.B. nach Rückkehr aus der Elternzeit oder Wiedereinstellung eines ausgeschiedenen Mitarbeiters). Hierzu haben wir unterschiedliche Vorgehensweisen bei unseren Kunden festgestellt:

1. Neuregistrierung des Benutzers
2. Wiederherstellung / Weiterverwendung früherer Daten

Beide Verfahren haben wir nachfolgend mit ihren Randbedingungen skizziert. Diese setzen voraus, dass auf den Servern die üblichen Funktionen (serverbasierte Zulassungsstelle, ID-Vault, MultiUser Client Installation, automatische Client Konfiguration) eingerichtet wurden:

1. Neuregistrierung des Benutzers

HINWEIS: Bei dieser Vorgehensweise ist vorab zu bemerken, dass die Neuregistrierung des Benutzers zur Erstellung einer neuen Benutzer-ID (mit neuen Schlüsseln) führt. Somit sind alle zuvor von diesem Benutzer (mit seiner ehemaligen ID) verschlüsselten Daten (Archive, lokale Datenbanken, etc.) sowie bislang vom Benutzer angelegten (und in seinem bisherigen ID File gespeicherten) Dokumentschlüssel verloren. Somit raten wir von dieser Methode DRINGEND ab, da es erfahrungsgemäß stets zu Folgeproblemem führt.

Bei der Registrierung prüft der der Domino Administrator Client, ob es einen Benutzer mit gleichem hierarchischem Namen im Directory oder im Vault gibt und läßt ggf. keine Registrierung zu, wenn der Name nicht eindeutig sein würde.



Stellt man nun fest, dass die bisherige Benutzer-ID noch im Vault vorhanden ist (entweder in Ansicht "Vault Users" oder Ansicht "Inactive User IDs") greifen Administroren nahezu logischerwiese dazu, diese noch vorhanden "Reste" aus dem Vault zu löschen und eine erneute Registrierung zu versuchen.

Das Ergebnis wird möglicherweise vergleichbar sein, da die Ansichtsindizes des Vault noch veraltet sein können/werden. Um diese zu aktualisieren, kann CRTL-SHIFT-F9 verwendet werden. So läßt sich der Benutzer im zweiten Anlauf registrieren (wenn man die ggf. zuvor schon angelegten Mailfile/Roaming Files mit anderem Namen erstellt oder überschreibt). Alles gut? Weit gefehlt.... Bei der Inbetriebnahme des Clients zeigen sich folgende Effekte:

Der Grund für die fehlgeschlagene Inbetriebnahme liegt nicht sofort auf der Hand, ist doch das Benutzer-ID File im Vault vorhanden. Die Ursache zeigt sich erst nach einem Blick in die Admin4.nsf:
Image:Gelöschte Benutzer wieder reaktivieren
Durch die beiden Versuche der erneuten Registrierung sind zwei Zertifizierungsaufträge erstellt worden (und der erste erfolgreich abgearbeitet). Die aktuell im Vault liegende Benutzer-ID ist somit noch nicht zertifziert. Um dieses zu erreichen, ist das oben markierte (zeitlich spätere) Auftragsdokument abzuarbeiten (>TE AdminP Process all). Vor einem erneuten Inbetriebnahmeversuch sind am IBM Notes Client alle bislang erstellten (unvollständigen) Konfigurations(teil)ergebnisse zu löschen (Windows Verzeichnis der MultiUser Installation).

Fazit: Einigermaßen aufwendig und störungsbehaftet !

2. Wiederherstellung / Weiterverwendung früherer Daten

Um einen zuvor gelöschten Benutzer wiederherzustellen sind:
  • Mailfile (und ggf. Roaming Files) bereitzustellen
  • Benutzer-ID (z.B. durch Aktivierung im Vault) bereitzustellen
  • Personendokument (mit Referenzen auf MailFile, RoamingFiles, sowie Public Key entsprechend der im Vault vorliegenden Benutzer-ID) anzulegen oder wiederherzustellen

Mailfile und RoamingFiles bereitstelllen

Die einfachste Methode hierfür ist, diese beim Löschen eines Benutzers nicht mit zu löschen (oder die entsprechenden Löschaufträge in der "Admin4.nsf" nicht zu bestätigen). In diesem Fall sind bei Rückkehr des Benutzers alle ehemaligen Daten unverändert vorhanden. Wurden diese jedoch gelöscht, so kann nur eine Dateiwiederherstellung aus einem (hoffentlich vorhandenen) Backup helfen. Wenn auch dieses nicht möglich ist, bietet sich nur die Methode "1. Neuregistrierung des Benutzers" mit allen seinen Nachteilen an.

Benutzer-ID bereitstellen
Findet sich die Benutzer-ID noch im Vault (Ansicht "Inactive User IDs") , so ist diese durch die Ansichtsaktion Image:Gelöschte Benutzer wieder reaktivieren wieder in den aktiven Zustand (für einen Download im Rahmen der Client Inbetriebnahme) zu versetzen. Fehlt diese, ist nur die Methode "1. Neuregistrierung des Benutzers" mit allen seinen Nachteilen an. Das Verfahren eine zuvor bei der Registrierung im Dateisystem des Administrator gesicherte Benutzer-ID zu verwenden mag hier als noch größere Fehlerquelle nicht weiter beleuchtet werden.

Personendokument bereitstellen

Personendokumente können interaktiv oder über die Benutzerregistrierung (Domino Administrator) erstellt werden. Bei interaktiver Erstellung ergibt sich die Schwierigkeit, dass die Felder für die Benennung der RoamingFiles nicht bearbeitbar sind. Bei Verwendung der Benutzerregistrierung werden jedoch neue Dateien (mit anderen Namen und neuem Inhalt) erstellt. In jedem Fall fehlen die Public Keys des Benutzers. Um dieses Problem zu umgehen, bleibt nur eine Empfehlung/Vorgehensweise: Vor der Löschung des Benutzers ist das Personendokument in eine separate Backup-Datenbank zu kopieren, um sie dann mit allen ehemaligen (korreten und vollständigen Informationen) in diesem Schritt wieder in das Domino Directory zurück zu kopieren.

Fazit: Vor der Löschung Personendokumente sichern, IDs im Vault deaktivieren bietet die besten Voraussetzungen, um ohne großen Aufwand ggf. alte Datensicherungen einzubringen und wenig Arbeit mit einer Reaktivierung zu haben ! Alles Andere produziert nicht unerheblichen Arbeitsaufwand und Streß.
Read full article |Kommentare deaktiviert für Gelöschte Benutzer wieder reaktivieren
Tags:
Categories: Allgemein
« Older Entries
Newer Entries »