Bearbeiten von „Fehlermeldungen ProMan, ProReg“

= Fehlermeldungen =

==="Viren- & Bedrohungsschutz: Aktion blockiert" verhindert das Anhängen vom ProReg.dotm===
Windowssymbol -> Zahnrad -> Update und Sicherheit -> Windows-Sicherheit -> Viren- & Bedrohungsschutz öffnen.
Unter "Einstellungen für Viren- & Bedrohungsschutz" auf "Einstellungen verwalten" klicken.
Unter "Ausschlüsse" auf "Ausschlüsse hinzufügen oder entfernen" klicken.
Mit dem Button ''+Ausschluss hinzufügen -> Datei'' das PreReg.dotm browsen und als Ausschluss eintragen.

===Die Methode DBEngine für das Object _Application ist fehlgeschlagen===
Beim Speichern des Protokolls erscheint die Meldung: "Die Methode DBEngine für das Object _Application ist fehlgeschlagen".
Im Ordner "C:\Program Files (x86)\Common Files\Microsoft Shared\DAO\" waren neben der üblichen dao360.dll noch zwei uralte Dateien von 1999, eine davon die dao350.dll, enthalten. In den Verweisen vom Proreg.dpt war eine Referenz auf diese uralte dll gesetzt,also auf die "Microsoft.DAO 3.51 Object Library" statt auf die "Microsoft.DAO 3.6 Object Library". Lösung:
Haken beim falschen Verweias entfernen und die richtige dll - falls sie unten nicht zur Auswahl steht - mit dem Button "Durchsuchen..." im obigen Pfad auswählen und anhaken.

Anderes Vorgehen:

Unter Verweise 

Microsoft Office 14.0 Access database engine Object Library

Priority mit den Pfeilen nach oben verschieben (an die 2. oder 3. Position)

===isysEloEG.exe stürzt nach dem Anzeigen des Fensters und vor Öffnen des Words ab===

Im MyCsharp-Forum habe ich folgenden Beitrag gefunden:
<br />
<br />
''Fehlermeldung:''<br />
''Ein Ausnahmefehler des Typs "System.InvalidCastException" ist in ConsoleApplication1.exe aufgetreten.''<br />
''Zusätzliche Informationen: Das COM-Objekt des Typs "Microsoft.Office.Interop.Excel.ApplicationClass" kann nicht in den Schnittstellentyp "Microsoft.Office.Interop.Excel._Application" umgewandelt werden. Dieser Vorgang konnte nicht durchgeführt werden, da der QueryInterface-Aufruf an die COM-Komponente für die Schnittstelle mit der IID "{000208D5-0000-0000-C000-000000000046}" aufgrund des folgenden Fehlers nicht durchgeführt werden konnte: Bibliothek nicht registriert. (Ausnahme von HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).''

Die Lösung lautete:

''Solution: This issue can be resolved by deleting an invalid registry key left over from the higher version of Office. Follow the Steps:''<br />
''Start--> Run --> regedit --> HKEY_CLASSES_ROOT-->TypeLib-->{00020813-0000-0000-C000-000000000046} --> 1.8/1.7 (Delete the key 1.8 if empty)''<br />
''Cause: This issue is caused by a left over registry key if you have downgraded your version of Microsoft Office from either Office 2010 to Office 2007, or Office 2013 to Office 2010 or 2007.''

Genauso wars bei mir, nur mit Word. Es wurde von 2016 auf 2013 downgegraded, worauf zum Beispiel bei Excel ein verwaister 1.9er Schlüssel an obiger Stelle war. Ich hab in der Nähe den entsprechenden Schlüssel vom Word gefunden und den leeren, höher nummerierten Schlüssel gelöscht, dann war gut. Bei mir  ist der Word-Schlüssel hier zu finden:


[[Datei:regedit.jpg|800px]]

===Word: Fehlende Verweise -> Fehler beim Zugriff auf die Systemregistratur===
Im Word sind laut Fehlermeldungen falsche Office-Verweise gesetzt, drückt man auf Extras -> Verweise kommt aber die Fehlermeldung "Fehler beim Zugriff auf die systemregistratur"
Dies liegt daran, dass der aktuelle Benutzer keine Administratorenrechte besitzt. Also den Benutzer wechseln zu einem Administratorenuser, nun das ProReg.dot öffnen und die Verweise korrigiern.
ACHTUNG: Unbedingt kontrollieren, ob sich das ProReg.dot auch gespeichert hat. Falls nicht, irgendwo im Code einen Leerschlag einfügen und nochmals speichern, bis das ProReg.dot ein aktuelles Änderungsdatum erhalten hat.
Nun sollte auch beim anderen Benutzerkonto alles funktionieren


===Access kann Word nicht öffnen===

1) Das Protokoll von Hand öffnen und nachschauen, ob es (oder ein anderes Protokoll) in den von Word deaktivierten Dokumenten aufgelistet ist. Falls ja, alle deaktivierten Dokumente wieder aktivieren:

[[Datei:FehlerWordOeffnen.png]]



2) Es sind nicht alle Gremien sauber auf Word 2010 umgestellt, nur einige. Dann kann es sein, dass in der Startprozedur eine andere Wordversion bestimmt wird, als Vorlage im Grmium vorhanden ist. -> Alle Gremien sauber auf 2010 umstellen.

===Access kann Datensatz nicht aktualisieren und behauptet die DB sei schreibgeschützt===

Access kann Datensätze in einer Abfrage nur aktualisieren, wenn die Tabellen in Beziehung zueinander stehen. Folgendes Beispiel aus der Speichern-Prozedur im ProReg.dot kann schiefgehen

[[Datei:DatensatzAktualisieren.png]]

* wenn die Beziehung zwischen tRegister und tGeschäft fehlt
* wenn die Primärschlüssel in tRegister und tGeschäft fehlen

===Word weigert sich, Dokumente am richtigen Pfad abzuspeichern===
Kontrollieren, ob in den Word-Optionen -> Addins -> Gehe zu COM AddIns, irgendwelche andere Addins (z.B. abDocs von Acer)  installiert sind. Alle überflüssigen entfernen. Dann gehts wieder.


===Registerkarte "AddIns" im Word nicht vorhanden===

* Die AddinIns sind in den "Word-Optionen -> Menüband anpassen" nicht aktiviert
* Eine andere Software hat den Menü-Reiter "Addins" umbenannt, zB. die VRSG Steuersoftware benennt den Reiter um in "Steuerdaten"
* In den Word-Optionen ist unter "Speichern" -> "Dokumente speichern" - > "Dateien in diesem Format speichern:" statt "Word-Dokument (*.docx)" etwas anderes eingetragen, zB. "Word-Vorlage (*.dotx)", was beim Speichern natürlich subito die AddIns rauswirft.

===Überprüfung, drücken Sie Esc um den Vorgang abzubrechen===
1. Den Pfad zum Applikationsordner im User-Laufwerk (und den Pfad zum Datenordner) in die vertrauenswürdige Speicherorte eintragen.<br />
2. Spoofingüberprüfungen etc. ausschalten gem. [[Diverse_Anleitungen_Man,_Reg#Word_2010_Sicherheitseinstellungen| Sicherheitseinstellungen im Word 2010]]

===Die Datenbank wurde von Benutzer 'Admin' auf Computer XY in einen Status versetzt, in dem sie nicht geöffnet oder gesperrt werden kann===

Verdacht: Die Datenbank wechselt bei Design-Änderungen (wie Manipulation der CommanBars, etc...) vom Share-Mode in den Exclusive-Mode und kommt da nicht mehr raus. Beim nächsten Zugriff auf die DB gibt es dann den Fehler 3734.

Ein Ansatz aus dem Netz, den Fehler zu vermeiden, ist hier beschrieben: [http://www.source-code.biz/snippets/vbasic/10.htm| How to avoid error 3734]. Da wird in der AutoExec-Funktion die Verbindung neu bzw. ein zweitesmal erstellt (Papa hat das mal eingebaut, mal schauen, ob das was nützt):

   Public Function Autoexec()
      Static Conn2 As Object: Set Conn2 = CreateObject("ADODB.Connection")
      Conn2.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & CurrentProject.FullName
   End Sub 

Ein anderer Post im Netz behauptet, dass beim Öffnen und Schliessen eines Fensters die Datenbank wieder in den Share-Modus zurückfindet: "I found one workaround: open any form and then close it. This seems to cause Access to reconsider whether it needs the database to stay in exclusive mode or not. This is pretty gross, however." Ein Lösungsansatz wäre also nach den ganzen Designänderungen im Hintergrund ein Fenster zu öffnen und dann wieder zu schliessen.

Dies wird bestätigt bei Frau Blasers Kollegin bei der EK Zürich. Öffnet sie ihre DB wird das Gremium automatisch gewechselt, weil sie ein anderes Startgremium hat. Öffnet sie nun ein Einzelgeschäft und versucht dieses zu speichern, kommt die obige Fehlermeldung.
Starte ich nun isys neu, öffne das Fenster "Gremien" und wähle das schon offene Gremium wieder aus, kann ich nachher das EG problemlos speichern...

===Frage, ob Änderungen in der Dokumentvorlage auch gespeichert werden sollen===
- Wordoptionen -> Erweitert -> Speichern -> "Bestätigung vor dem Speichern von Normal.dot" deaktivieren<br/>
- Entfernen von Add-Ins oder Makros, die die globale Vorlage ändern gemäss [http://support.microsoft.com/kb/918064 Microsoft-Hilfe]: Problemumgehung 2, Methode 2<br/>
- Alle anderen Vorschläge von [http://support.microsoft.com/kb/918064 Microsoft-Hilfe] ausprobieren<br/>

===Textmarke Nummer fehlt, aber die Textmarke ist in der Vorlage vorhanden===

* Es kann sein, dass Word die Protvorlage in der geschützten Ansicht aufmachen muss (wegen den Sicherheitseinstellungen), dann kann natürlich kein Code ablaufen. In diesem Fall den Ordner ProMan in den Wordoptionen in die geschützten Speicherorte eintragen. Falls das nicht möglich ist, dann die Häkchen in den geschützten Ansichten rausnehmen (Unsichere Speicherort und Internet).

* Das Zusammenspiel von Access und Word funktioniert nicht (relativ häufig in Office 2010):
** Erste Aktion: In der ini-Datei unter [Optionen] StartModus=2 eintragen. Dann wird Word mit anderem Kommando aufgerufen. Das hilft bis heute immer. Wenn nicht:
** Zweite Aktion: Die Texmarke Nummer wird von der Textmarke Nummer1 (aus der Kopfzeile) gekillt, wenn möglich diese löschen. Dasselbe gilt für die Textmarken Datum und Datum1. Vorlage ist kaputt, aus unserer Vorlage Protokoll.dot eine neue Vorlage erstellen. Wenn nicht:
** Dritte Aktion: StartModus=3. Hier muss dann ProReg/ManDokNeu.doc im Startverzeichnis vorhanden sein

=== Die Datei System.mdw fehlt ===
Sie ist zum Start des Programms erforderlich	
System.mdw steht bei Access-Runtime-Installationen bei und im Ordner isys-Protokollregister / manager. Wenn sie dort fehlt, Runtime nochmals installieren.
Wenn wir kein Runtime installiert haben, weil der Rechner ein normales ACCESS hat, dann kommt diese Fehlermeldung, wenn ProReg/ProMan.mde implizit ein Runtime-Access startet. Das kann man verifizieren, indem man das normale Access normal startet und wieder schliesst. Dann ruft unser Programm wieder dieses Access auf.
Sichern dieses Ablaufs, indem man im isys-Icon unter Ziel den Pfad des normalen Acces aufführt. Beispiel: "C:\Programme\Microsoft Office\Office\MSACCESS.EXE" C:\Programme\isys-Protokollregister\ProReg.mde

=== Ungültige Formatvorlage ===	
Ein Protokoll wird aufgerufen und zeigt keine Kommandos. Extras / Vorlagen & AddIns weist auf C:\Programme\isys-Protokollregister\ProReg.dot. Beim Schliesen des Fensters kommt "Ungültige Formatvorlage".
Ist auch schon in ähnlicher Form bei einem neuen Protokoll aufgetreten.
Grund: Im Ordner \ProReg\ oder \Protokolle\ gibt es ein ProReg.dot
Löschen und gut.


=== Ausdruck (?) steht in Ausdrücken nicht zur Verfügung ===	
Hinweis auf falsche oder fehlende Bibliothek.
Nach der Installation einer neuen ProReg/ProMan.mde tritt dieser Fehler auf, wenn man das Protokollregister aufrufen will.
Zugehörige ProReg.mdb mit Shift öffnen. Module / Prozeduren aufrufen und unter Extras / Verweise nachsehen. 
Manchmal fehlt ein (überflüssiger) Webdienst. Hinweis deaktivieren.
Oder es fehlt die passende Office Project Library. Z. B. 8.0 statt 10.0. Entsprechend korrigieren.


=== Dokumentvorlage kann nicht geändert werden ===
Beim Einrichten eines neuen Protokolls fehlen die isys-Kommandos.
Extras / Vorlagen und AddIns zeigt Verbindung mit Protokoll.dot. Ändern auf …/ProReg.dot bringt die Fehlermeldung.
Grund: Fehler in ProReg.dot. Fehlende ACCESS-Bibliothek
ProReg.dot öffnen, Alt-F11 zum Öffnen von Visual Basic und über Extras / Verweise den Verweis auf die korrekte ACCESS-Version herstellen.


=== Das angeforderte Element ist in der Sammlung nicht vorhanden ===	
Kann leider alles Mögliche sein. Rechner neu starten und wenn das nix hilft debuggen.


=== Datensatz gelöscht ===
Tritt auf beim Speichern eines Protokolls. 
Datenbank ProRegDaten.mdb reparieren und komprimieren.


=== ACCESS kann nicht speichern ===
, weil ein anderer Benutzer dieselben Daten bearbeitet ,… oder so ähnlich. 	
ProRegDaten ist defekt. Reparieren und komprimieren.


=== Doppelte Einträge im Stichwortregister ===	
Alle Einträge im Stichwortregister sind doppelt.
In tAllgemein gibt es eine zweite Zeile mit dem Jahrgang.
Diese Zeile löschen.


=== Protokoll aufrufen findet ein vorhandenes Protokoll nicht ===	
Protokoll aufrufen zeigt eine Protokollnummer mit Datum an. Beim Aufruf öffnet sich Word, aber der Bildschirm bleibt grau. Das Protokoll wird nicht geöffnet.
Das Protokoll ist im Protokollordner vorhanden und kann mit dem Explorer geöffnet, bearbeitet und gespeichert werden. ProReg findet sie aber nicht wieder.
Grund. Eine Protokolldatei mit demselben Namen liegt in "Eigene Dateien".
Lösung: Die Datei in "Eigene Dateien" löschen.


=== Fehler bei Aufruf eines neuen Einzelgeschäfts ===
Obwohl mit Einzelgeschäft.dot gearbeitet wird, wird die Startprozedur von früheren Einzelgeschäft.doc gestartet, und die findet die Prozedur Pend.RessAuswahl nicht.
Startprozedur im Einzelgeschäft.dot entfernen.


=== Der Wert für das Mass muss zwischen 0 pt und 1584 pt liegen	===
Tritt auf beim Anlegen der Traktandenliste oder beim Anlegen neuer Traktanden, wenn zu RegSpalten Angaben in der ini-Datei stehen und in der Systemsteuerung als Regions- und Sprachoption Deutsch(Deutschland) eingestellt ist. Dann konvertiert ProMan.dot bzw. ProReg.dot die Zahlen falsch.
Systemsteuerung / Regions- und Sprachoption auf Deutsch(Schweiz) stellen.


===Converter mswrd632.wpc ===

“Word cannot start the converter mswrd632.wpc”

Der Fix von Microsoft kann hier oder auf unserer Homepage unter "Wartung" downgeloadad und installiert werden!
<br />
[http://www.isys-informatik.ch/images/stories/MicrosoftFixit50352.msi  Download Fix]
<br />
<br />

=== Fehler beim erstellen Neues Protokoll" ProMan.dot nicht gefunden"===
Lösung: Neue .mde erstellen, danach sollte es gehen!

=== Beim Start der .mde kommt: "Cannot find Language.dll" ===
Lösung: Einmal die .mdb starten, dann sollte es wieder gehen.


=== Pendenzliste ist sehr "luftig", d.h. sie hat übergrosse Zeilenabstände ===
In der Vorlage "Normal.dot" stehen im Format "Standard" unter "Absatz" komische Werte.
Die kann man korrigieren, indem man das Format aus einem Dokument mit vernünftigen Werten über "Formatvorlagen verwalten" in das "Normal.dot" kopiert.

==="Fehler beim Laden einer dll"===
Nachsehen, ob unter Extras/Verweise "Microsoft DAO 3.6 Object Library" aufgeführt ist.
Wenn sie nicht vorhanden ist,
"C:\Program Files\Common Files\Microsoft Shared\DAO\dao360.dll"
von einem beliebigen Rechner holen und hier einkopieren.

===Meldung beim Speichern:"Auf ...\ProRegdaten.mdb  kann nicht zugegriffen werden..."===
Unter [Pendenzen]Fremde= sind Inis eingetragen mit Pfaden, auf die nicht zugegriffen werden kann.

Diese Einträge beseitigen. Ab ProReg.dot 19.0.10 behoben.

===Bug bei Windows Update Access geht nicht mehr Windows Vista/ Windows 7 ===

'''Behebung: Deinstallation von Update KB3085515'''


[https://social.msdn.microsoft.com/Forums/de-DE/41b0402b-c602-47f9-85a6-d9eb78978a36/probleme-mit-kb3085515-zur-info?forum=accessde Update KB3085515]

''Windows Vista''
Systemsteuerung -> Programme und Funktionen -> Installierte Updates anzeigen

''Windows 7''
Systemsteuerung  -> System und Sicherheit und es öffnet sich folgendes Fenster.

[[Datei:Neu1.jpeg]]

Ein Klick auf Windows Update öffnet dann ein weiteres Fenster mit Informationen zum aktuellen Stand der Windows Updates.

[[Datei:Bild 2.jpeg]]

Hier findet man nun die gesuchte Möglichkeit sich die installierten Updates anzeigen zu lassen. Im linken Menü befindet sich ein Link mit dem passenden Namen: Updateverlauf anzeigen. Ein Klick darauf öffnet ein Fenster in dem alle installierten Updates aufgelistet sind.


[[Datei:3.jpg]]

''Windows 10''

Klicke mit der rechten Maustaste auf das Windows-Logo
Klicke auf Programme und Features

[[Datei:4.png]]

Auf der linken Seite klicke auf Installierte Updates anzeigen

[[Datei:5.png]]


Jetzt kannst du alle Updates sehen, die jemals installiert wurden

[[Datei:6.png]]


===Sortierung der Pendenzlisten nach Pendenznummer===

In alten Datenbanken ProRegDaten.mdb ist in tPendenz die PendenNummer GeschNr als Text definiert. Dann werden die Nummern als Text nummeriert wie: 10, 11, 1, 2 usw.

Ändert man die Definition der GeschNr auf Zahl um (die nötige Konvertierung macht ACCESS automatisch), dann kommt die Sortierung richtig.

HK 14.10.2019