Hallo zusammen,
wir haben hier seit einiger Zeit ein Konfigurationsproblem, das jetzt gelöst werden muss, weil der WebAccess nun auch nicht mehr funktioniert (gleiche Fehlermeldung wie unten beschrieben).
Die Anmeldung an der Postgres-Datenbank klappt sowohl mit „SRV118“ als auch mit „srv118“. (Verrückte Welt.) Aktuelle Änderungen sind aber immer nur im „srv118“ vorhanden. (Verrückte Welt!) Meldet man sich auf „SRV118“ an [Datei > Optionen > Datenbank-Anmeldung], gibt es nach dem Neustart eine Fehlermeldung für die zuletzt erstellten Tabellen und Sichten:
Es bestehen Inkonsistenzen… Ansichten, die auf einer unbekannten Datenbank-Tabelle/Sicht basieren: [mehrere aufgelistet] … Um die jeweilige Ansichtskonfiguration anzupassen, rufen Sie die Eigenschaften der Ansichten auf.
Nach verzweifelten Versuchen (erneute Installation, schauen, welche Dateien zuletzt verändert wurden, Unterschiede zwischen Groß- und Kleinschreibung untersucht wie Ping, Mac-Adresse) habe ich heute auf diese Weise eine Ansicht zerstört.
- Anmelden an SRV118, Neustart, Fehler wie üblich
- Aufruf der Ansichtskonfiguration für Ansicht X, kleine Änderung, Projekt gespeichert
- Anmelden an srv118, Neustart, jetzt kommt hier die Meldung für Ansicht X
- Aufruf der Ansichtskonfiguration für Ansicht X, keine Datenbanktabelle zugeordnet, alle Feldaliase und Relationen verloren
Kann mir jemand dieses Phänomen erklären? An welcher Stelle kann ich die SRV118-Einträge hart in srv118 ändern? Wie kann ich zukünftig eine Anmeldung an SRV118 verhindern? Was muss ich beim WebAccess ändern?
Vielen Dank.
Christian
Hi,
an folgenden Stellen steckt der Datenbankserver-Name (soweit ich weiß)
Registry aller Clients, konkret: HKEY_CURRENT_USER\Software\combit\combit Relationship Manager\Settings\DBServer=
Schema.ini im Installationsordner (kannst mit Notepad direkt drin editieren)
project.cfg (für WebAccess und wird durch das WebDeploy erzeugt, kannst mit Notepad direkt drin editieren)
client.config im Installationsordner, falls vorhanden (kannst mit Notepad direkt drin editieren)
Wenn du die alle (!) gleichzeitig vereinheitlichst (welche Schreibweise ist egal) und danach (!) auf einem Client den cRM startest und Datei > Projekt-Administration > Reorganisieren aufrufst und dann den cRM nochmal neu startest, dann ist das Problem (für alle) weg.
Hintergrund: cRM cached sich seit V7 das Datenbankschema, er merkt sich das in der cmbt_Data Tabelle der Solution unter einem Eintrag, der so heißt wie der Server. Wenn du nun über den cRM was am Datenbank-Schema änderst (Tabellen/Felder hinzufügst/änderst/löschst), dann forciert der cRM eine Neu-Erzeugung dieses Caches (wohlgemerkt unter dem Server-Namen, mit dem er aktuell verbunden ist).
Vermutung: Offensichtlich wird dabei Groß-/Kleinschreibung berücksichtigt (liegt evtl. an Postgres), so dass die Clients/WebAccess, die mit anderer Server-Schreibweise zugreifen, diesen Eintrag ja nicht finden (bzw. suchen), sondern den mit einer anderern („ihrer“) Schreibweise des Server-Namens, und der darunter gefundene Cache ist jetzt veraltet. Dadurch scheinen diese Clients/WebAccess die Änderungen an der Datenbankstruktur nicht „zu sehen“. Bei Postgres kann der cRM nicht automatisch merken, dass der Cache veraltet ist (siehe Handbuch) - daher musst du das nach der Vereinheitlichung über Reorganisieren einmal forcieren…
Gruß
Alex
Vielen Dank für die Antwort. Die letzte Reorganisation habe ich bereut, siehe anderer Thread von mir. Die anderen Tipps schaue ich mir morgen an.
Edit 6.7.: Bisher war ich noch nicht erfolgreich. In der Tabelle „cmbt_Data“ habe ich den SRV118 gefunden und umbenannt: „SchemaCache@SRV118“ -> „SchemaCache@SRV118x“. Da das nicht geholfen hat, drei Folgefragen:
- Spricht etwas dagegen, die Einträge ganz zu löschen?
- Wo könnte der Server im Postgres noch hinterlegt sein? (Dass es am Postgres liegt, ist glaube ich eine richtige und wichtige Vermutung.)
- Kann ich irgendwie mehrere Tabellen durchsuchen? Im pgAdmin sehe ich keine Möglichkeit.
Edit wenige Minuten später: Geistesblitz! In der „cmbt_Data“ gab es auch noch einen Cache für „localhost“, der seit Monaten nicht aktualisiert wurde. Der war auch in der project.cfg eingetragen. Geändert -> geht. Vielen Dank für den Hinweis darauf. Über eine Antwort zu 1. würde ich mich unabhängig davon freuen.
Hi Christian,
(besser spät als nie 
) meine persönliche Einschätzung zu 1.:
kannste m.M.n. löschen, mir hat combit mal in einer Admin Schulung gesagt, dass wenn der SchemaCache Eintrag nicht da ist, aber benötigt wird, dann wird er automatisch erzeugt. So war es beim damaligen Update von V6 auf V7 auch, der Eintrag wurde dann erzeugt, als ich den cRM nach dem Update dann mit meiner Solution zum ersten Mal öffnete (oder beendete - weiß ich nicht mehr).
Gruß
Alex
