17
ESTOS ProCall ODBC Datenquelle verteilen
Mahlzeit!
Wir nutzen derzeit ESTOS ProCall 6.2.4.1484 auf Windows 2012 R2 als RD-SH. Derzeit werden Kontakte über Outlook \ Öffentliche Ordner durchsucht. Um von Outlook unabhängig zu werden möchte ich eine ODBC Datenquelle anzapfen und diese Konfiguration zentral verteilen.
Ich habe für die Kontakte eine SQL View angelegt, darauf haben alle berechtigten Benutzer mit ihrer Windows-Anmeldung Zugriff. Die Datenbank habe ich an allen RD-SH als System DSN eingerichtet. In ProCall habe ich die ODBC Verbindung eingerichtet und das klappt, ProCall findet die Kontakte.
Dann habe ich aus der XML unter
C:\Users\<benutzer>\AppData\Roaming\ESTOS\ProCall 6\databases.xml
den ODBC Abschnitt genommen und in eine eigene supplied_databases.xml im NETLOGON Verzeichnis ausgelagert. Per Registry Key wird die XML von ProCall auch verarbeitet, die ODBC Verbindung wird beim Start eingetragen. Nur Kontakte darin suchen, das klappt dann nicht mehr.
Das ganze ist hier beschrieben:
https://support.estos.de/de/procall-enterprise/best-practice-administrat ...
Leider wird die XML nur grob erklärt. Ich weiß nicht, ob Parameter wie z.B. <Supplied>1</Supplied> gesetz sein müssen, ich denke schon. Darüber hinaus habe ich keine Idee warum die Konfiguration zwar in ProCall eingetragen wird aber nicht mehr durchsuchbar ist.
Heute Abend mache ich ein Update auf die letzte 6.4 Version.
Hat hier jemand eine zentrale Datenquelle für ProCall per XML verteilt und noch eine Idee?
Wir nutzen derzeit ESTOS ProCall 6.2.4.1484 auf Windows 2012 R2 als RD-SH. Derzeit werden Kontakte über Outlook \ Öffentliche Ordner durchsucht. Um von Outlook unabhängig zu werden möchte ich eine ODBC Datenquelle anzapfen und diese Konfiguration zentral verteilen.
Ich habe für die Kontakte eine SQL View angelegt, darauf haben alle berechtigten Benutzer mit ihrer Windows-Anmeldung Zugriff. Die Datenbank habe ich an allen RD-SH als System DSN eingerichtet. In ProCall habe ich die ODBC Verbindung eingerichtet und das klappt, ProCall findet die Kontakte.
Dann habe ich aus der XML unter
C:\Users\<benutzer>\AppData\Roaming\ESTOS\ProCall 6\databases.xml
den ODBC Abschnitt genommen und in eine eigene supplied_databases.xml im NETLOGON Verzeichnis ausgelagert. Per Registry Key wird die XML von ProCall auch verarbeitet, die ODBC Verbindung wird beim Start eingetragen. Nur Kontakte darin suchen, das klappt dann nicht mehr.
Das ganze ist hier beschrieben:
https://support.estos.de/de/procall-enterprise/best-practice-administrat ...
Leider wird die XML nur grob erklärt. Ich weiß nicht, ob Parameter wie z.B. <Supplied>1</Supplied> gesetz sein müssen, ich denke schon. Darüber hinaus habe ich keine Idee warum die Konfiguration zwar in ProCall eingetragen wird aber nicht mehr durchsuchbar ist.
Heute Abend mache ich ein Update auf die letzte 6.4 Version.
Hat hier jemand eine zentrale Datenquelle für ProCall per XML verteilt und noch eine Idee?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7804848924
Url: https://administrator.de/contentid/7804848924
Ausgedruckt am: 18.11.2024 um 17:11 Uhr
17 Kommentare
Neuester Kommentar
Hallo,
ja, hier ist noch jemand, der Datenquellen via XML an die Clients ausrollt und die Daten auch erfolgreich innerhalb von ProCall verarbeitet werden. Wir benutzen allerdings ProCall 7.
Wie sieht die ODBC-Verbindung in ProCall denn unter den Datenquellen aus, nachdem diese beim Start übernommen wurde? Hat diese zufällig ein kleines Ausrufezeichen am Symbol?
Was du auf jeden Fall machen musst und meines Erachtens auch gemacht hast, ist, dass das XML-File den kompletten
<ODBC>…</ODBC>
- Tag beinhalten muss.
Der Wert innerhalb von <Supplied></Supplied> ist für unsere Datenquellen übrigens als 0 angegeben. Sagt aus, ob die Anwendung es angewendet hat oder nicht.
Wenn du nicht suchen kannst, kann es beispielsweise auch daran liegen, das du die Datenquellen nicht zum Durchsuchen konfiguriert hast oder während des Suchens in der Anwendung die Datenquelle nicht mit einbezogen wird.
Falls das nicht hilft, kannst du den Inhalt der Datei mal ohne den <connect>…</connect> - String einmal posten.
ja, hier ist noch jemand, der Datenquellen via XML an die Clients ausrollt und die Daten auch erfolgreich innerhalb von ProCall verarbeitet werden. Wir benutzen allerdings ProCall 7.
Wie sieht die ODBC-Verbindung in ProCall denn unter den Datenquellen aus, nachdem diese beim Start übernommen wurde? Hat diese zufällig ein kleines Ausrufezeichen am Symbol?
Was du auf jeden Fall machen musst und meines Erachtens auch gemacht hast, ist, dass das XML-File den kompletten
<ODBC>…</ODBC>
- Tag beinhalten muss.
Der Wert innerhalb von <Supplied></Supplied> ist für unsere Datenquellen übrigens als 0 angegeben. Sagt aus, ob die Anwendung es angewendet hat oder nicht.
Wenn du nicht suchen kannst, kann es beispielsweise auch daran liegen, das du die Datenquellen nicht zum Durchsuchen konfiguriert hast oder während des Suchens in der Anwendung die Datenquelle nicht mit einbezogen wird.
Falls das nicht hilft, kannst du den Inhalt der Datei mal ohne den <connect>…</connect> - String einmal posten.
Okay <Supplied></Supplied> habe ich wieder zurück gesetzt. Ich hatte zunächst alles 1:1 kopiert, erst als es nicht richtig lief habe ich den Inhalt wirklich verändert um zu sehen ob sich was tut.
Es geht weder die Suche bei einkommenden Anrufen noch bei Eingabe eines Suchbegriffs direkt in ProCall.
Es geht weder die Suche bei einkommenden Anrufen noch bei Eingabe eines Suchbegriffs direkt in ProCall.
<ODBC>
<StandardSearch>1</StandardSearch>
<SearchOnCall>1</SearchOnCall>
<MandantSearch>0</MandantSearch>
<PhoneBookSearch>0</PhoneBookSearch>
<Removable>1</Removable>
<Supplied>0</Supplied>
<DatabaseSettings>
<Editable>1</Editable>
<DatabaseType>5</DatabaseType>
<OperationMode>4</OperationMode>
<HideDatabaseChooser>1</HideDatabaseChooser>
<LicensedConnectors>0</LicensedConnectors>
<OutboundReplicator>0</OutboundReplicator>
<MetaServerPort>712</MetaServerPort>
<MetaServerHost>localhost</MetaServerHost>
<MetaServerPassword></MetaServerPassword>
<MetaServerBaseDN>dc=meta</MetaServerBaseDN>
<MetaServerFilter>objectclass=contactperson</MetaServerFilter>
<Source>
<UserName></UserName>
<Password></Password>
<Host></Host>
<Port>0</Port>
<Filename></Filename>
<Formular></Formular>
<Frameset></Frameset>
<Owner>dbo</Owner>
<Folder>procall</Folder>
<Database></Database>
<SearchBase></SearchBase>
<SearchFilter></SearchFilter>
<LocationAreaCode></LocationAreaCode>
<LocationPBXRoot></LocationPBXRoot>
<LengthInternalNumbers>3</LengthInternalNumbers>
<IncludeSubdirectories>1</IncludeSubdirectories>
<CountryID>49</CountryID>
<TextFileFirstLineIsHeader>0</TextFileFirstLineIsHeader>
<ShowODBCDatabaseAccessConflict>0</ShowODBCDatabaseAccessConflict>
<ShowExtendedFieldSettings>0</ShowExtendedFieldSettings>
</Source>
<SourceLDAP>
<UseSSL>0</UseSSL>
<Version>3</Version>
<MultiRowFetching>0</MultiRowFetching>
<UserAuthentication>0</UserAuthentication>
<Timeout>5</Timeout>
<MaxResults>50</MaxResults>
</SourceLDAP>
<DestinationLDAP>
<Host></Host>
<Password></Password>
<Port>712</Port>
<Node></Node>
</DestinationLDAP>
<PrePostApplications>
<PreEnabled>0</PreEnabled>
<PreLocation></PreLocation>
<PostEnabled>0</PostEnabled>
<PostLocation></PostLocation>
</PrePostApplications>
<MetaDirectory>
<ReplicatorName>MSSQL ODBC CRM</ReplicatorName>
<RunAsUser></RunAsUser>
<RunAsPassword></RunAsPassword>
<RunAsDomain></RunAsDomain>
<StartTime>10.07.2023 13:16:50:099</StartTime>
<NextRunTime>00.00.0000 00:00:00:000</NextRunTime>
<LastRunTime>00.00.0000 00:00:00:000</LastRunTime>
<RunCount>0</RunCount>
<Running>0</Running>
<RunResult>0</RunResult>
<RegularExpression></RegularExpression>
<RegularExpressionReplace></RegularExpressionReplace>
<RepeatReplicator>1</RepeatReplicator>
<RepeatMinutes>15</RepeatMinutes>
<DebugLevel>0</DebugLevel>
<LogFilePath></LogFilePath>
<NoReplicatorLog>0</NoReplicatorLog>
</MetaDirectory>
<ActiveDirectory>
<Filter></Filter>
</ActiveDirectory>
<Mapi>
<Profilename></Profilename>
</Mapi>
<Notes>
<IniPath></IniPath>
<UseIni>0</UseIni>
</Notes>
<Datev>
<ActiveMandants>15</ActiveMandants>
<ReplicateInactiveMandants>1</ReplicateInactiveMandants>
<CommunicationDetailsAsContactPerson>0</CommunicationDetailsAsContactPerson>
</Datev>
<ODBC>
<Connect>$ziemlichlangerwurstsalat</Connect>
<SelectStatement></SelectStatement>
<UseSelectStatement>0</UseSelectStatement>
<ShowODBCConnect>1</ShowODBCConnect>
</ODBC>
<Text>
<TextFieldSeperator>;</TextFieldSeperator>
</Text>
<Target>
<Filename></Filename>
</Target>
<XML>
<SourceXMLProfilename></SourceXMLProfilename>
</XML>
<ContactURL>
<ContactURL></ContactURL>
<ContactURLDescription></ContactURLDescription>
<ContactURL2></ContactURL2>
<ContactURLDescription2></ContactURLDescription2>
<ContactURL3></ContactURL3>
<ContactURLDescription3></ContactURLDescription3>
</ContactURL>
<Fieldmappings>
<Mapping name="Index" idi="-1" ids="entryID" idx="1" phone="0">
<Field ids="Index" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Angezeigter Name" idi="-1" ids="displayName" idx="0" phone="0">
<Field ids="Angezeigter Name" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Vorname" idi="-1" ids="givenName" idx="0" phone="0">
<Field ids="Vorname" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Nachname" idi="-1" ids="sn" idx="0" phone="0">
<Field ids="Nachname" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Position" idi="-1" ids="title" idx="0" phone="0">
<Field ids="Position" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Firma" idi="-1" ids="company" idx="0" phone="0">
<Field ids="Firma" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Abteilung" idi="-1" ids="department" idx="0" phone="0">
<Field ids="Abteilung" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Büro" idi="-1" ids="physicalDeliveryOfficeName" idx="0" phone="0" />
<Mapping name="Straße geschäftlich" idi="-1" ids="streetAddress" idx="0" phone="0">
<Field ids="Straße geschäftlich" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Postleitzahl geschäftlich" idi="-1" ids="postalCode" idx="0" phone="0">
<Field ids="Postleitzahl geschäftlich" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Stadt geschäftlich" idi="-1" ids="l" idx="0" phone="0">
<Field ids="Stadt geschäftlich" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Bundesland geschäftlich" idi="-1" ids="st" idx="0" phone="0" />
<Mapping name="Land geschäftlich" idi="-1" ids="c" idx="0" phone="0" />
<Mapping name="Straße privat" idi="-1" ids="privateAddressStreet" idx="0" phone="0">
<Field ids="Straße privat" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Postleitzahl privat" idi="-1" ids="privateAddressPostalCode" idx="0" phone="0">
<Field ids="Postleitzahl privat" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Stadt privat" idi="-1" ids="privateAddressCity" idx="0" phone="0">
<Field ids="Stadt privat" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Bundesland privat" idi="-1" ids="privateAddressState" idx="0" phone="0" />
<Mapping name="Land privat" idi="-1" ids="privateAddressCountry" idx="0" phone="0" />
<Mapping name="Straße weitere" idi="-1" ids="otherAddressStreet" idx="0" phone="0" />
<Mapping name="Postleitzahl weitere" idi="-1" ids="otherAddressPostalCode" idx="0" phone="0" />
<Mapping name="Stadt weitere" idi="-1" ids="otherAddressCity" idx="0" phone="0" />
<Mapping name="Bundesland weitere" idi="-1" ids="otherAddressState" idx="0" phone="0" />
<Mapping name="Land weitere" idi="-1" ids="otherAddressCountry" idx="0" phone="0" />
<Mapping name="E-Mail geschäftlich" idi="-1" ids="mail" idx="0" phone="0">
<Field ids="E-Mail geschäftlich" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="E-Mail privat" idi="-1" ids="mail2" idx="0" phone="0">
<Field ids="E-Mail privat" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="E-Mail weitere" idi="-1" ids="mail3" idx="0" phone="0">
<Field ids="E-Mail weitere" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="SIP Adresse" idi="-1" ids="sipAddress" idx="0" phone="0" />
<Mapping name="Webseite" idi="-1" ids="url" idx="0" phone="0">
<Field ids="Webseite" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Telefon geschäftlich" idi="-1" ids="telephoneNumber" idx="0" phone="1">
<Field ids="Telefon geschäftlich" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Telefon geschäftlich 2" idi="-1" ids="otherTelephone" idx="0" phone="1">
<Field ids="Telefon geschäftlich 2" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Telefon Firma" idi="-1" ids="telephoneNumberCompanyMain" idx="0" phone="1">
<Field ids="Telefon Firma" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Telefon Assistent" idi="-1" ids="telephoneAssistant" idx="0" phone="1" />
<Mapping name="Telefon privat" idi="-1" ids="homephone" idx="0" phone="1">
<Field ids="Telefon privat" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Telefon privat 2" idi="-1" ids="otherHomePhone" idx="0" phone="1" />
<Mapping name="Telefon primär" idi="-1" ids="telephonePrimary" idx="0" phone="1" />
<Mapping name="Telefon mobil" idi="-1" ids="mobile" idx="0" phone="1">
<Field ids="Telefon mobil" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Telefon Auto" idi="-1" ids="telephoneCar" idx="0" phone="1" />
<Mapping name="Telefon Radio" idi="-1" ids="telephoneRadio" idx="0" phone="1" />
<Mapping name="Pager" idi="-1" ids="pager" idx="0" phone="1" />
<Mapping name="Telefon Callback" idi="-1" ids="telephoneCallback" idx="0" phone="1" />
<Mapping name="Telefon ISDN" idi="-1" ids="telephoneISDN" idx="0" phone="1" />
<Mapping name="Telefon TTYTTD" idi="-1" ids="telephoneTTYTTD" idx="0" phone="1" />
<Mapping name="Fax geschäftlich" idi="-1" ids="facsimileTelephoneNumber" idx="0" phone="1">
<Field ids="Fax geschäftlich" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Fax privat" idi="-1" ids="otherFacsimileTelephoneNumber" idx="0" phone="1" />
<Mapping name="Kundennummer" idi="-1" ids="customerid" idx="0" phone="0" />
<Mapping name="DirectWebLink" idi="-1" ids="directWebLink" idx="0" phone="0" />
<Mapping name="Kontakt-Bildpfad" idi="-1" ids="imagePath" idx="0" phone="0" />
<Mapping name="DirectOpenContact" idi="-1" ids="directOpenContact" idx="0" phone="0" />
<Mapping name="Notiz" idi="-1" ids="info" idx="0" phone="0" />
<Mapping name="Benutzer 0" idi="-1" ids="custom0" idx="0" phone="0">
<Field ids="Benutzer 0" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Benutzer 1" idi="-1" ids="custom1" idx="0" phone="0">
<Field ids="Benutzer 1" idi="-1" prepend="" append="" regsearch="" regreplace="" />
</Mapping>
<Mapping name="Benutzer 2" idi="-1" ids="custom2" idx="0" phone="0" />
<Mapping name="Benutzer 3" idi="-1" ids="custom3" idx="0" phone="0" />
<Mapping name="Benutzer 4" idi="-1" ids="custom4" idx="0" phone="0" />
<Mapping name="Benutzer 5" idi="-1" ids="custom5" idx="0" phone="0" />
<Mapping name="Benutzer 6" idi="-1" ids="custom6" idx="0" phone="0" />
<Mapping name="Benutzer 7" idi="-1" ids="custom7" idx="0" phone="0" />
<Mapping name="Benutzer 8" idi="-1" ids="custom8" idx="0" phone="0" />
<Mapping name="Benutzer 9" idi="-1" ids="custom9" idx="0" phone="0" />
<Mapping name="Benutzer 10" idi="-1" ids="custom10" idx="0" phone="0" />
<Mapping name="Benutzer 11" idi="-1" ids="custom11" idx="0" phone="0" />
<Mapping name="Benutzer 12" idi="-1" ids="custom12" idx="0" phone="0" />
<Mapping name="Benutzer 13" idi="-1" ids="custom13" idx="0" phone="0" />
<Mapping name="Benutzer 14" idi="-1" ids="custom14" idx="0" phone="0" />
<Mapping name="Benutzer 15" idi="-1" ids="custom15" idx="0" phone="0" />
<Mapping name="Benutzer 16" idi="-1" ids="custom16" idx="0" phone="0" />
<Mapping name="Benutzer 17" idi="-1" ids="custom17" idx="0" phone="0" />
<Mapping name="Benutzer 18" idi="-1" ids="custom18" idx="0" phone="0" />
<Mapping name="Benutzer 19" idi="-1" ids="custom19" idx="0" phone="0" />
</Fieldmappings>
</DatabaseSettings>
</ODBC>
Hast du <SelectStatement></SelectStatement> bewusst geleert oder ist dieses in deiner Konfiguration leer? Wenn es wirklich leer ist, hast du hier die Ursache, da schlichtweg keine Anfrage an den DB-Server gestellt wird.
<Removable>1</Removable> macht bei einer systemverteilten Quelle keinen Sinn, da sie der Anwender so selber löschen könnte. Würde ich persönlich daher mit dem Wert 0 versehen.
Wie sieht die Datenquelle in der Auflistung im ProCall-Client aus?
<Removable>1</Removable> macht bei einer systemverteilten Quelle keinen Sinn, da sie der Anwender so selber löschen könnte. Würde ich persönlich daher mit dem Wert 0 versehen.
Wie sieht die Datenquelle in der Auflistung im ProCall-Client aus?
Hm ich habe in SQL eine View die genau das liefert was da sein soll und auch genau die Spaltennamen von Procall gesetzt. Wenn ich das manuell anlege klappt das, obwohl ich kein Select-Statement setze, ich wähle nur die Tabelle aus. In der databases.xml steht dann
Wie gesagt, ich hab das erstmal 1:1 in die supplied_databases.xml übernommen.
Wenn ich das bei der manuellen Einrichtung mit Select Statement anlege steht in der databases.xml
Dann geht die Suche auch wieder nicht, interessanter Weise hat er dabei 3 Datenquellen, die zentral verteilte, die manuelle Einrichtung ohne Select und die manuelle Einrichtung mit Select. Er hat jetzt aber keinen einzigen Treffer mehr, unabhängig von der Reihenfolge der Datenquellen.
Vielleicht habe ich Glück und ich muss tatsächlich einfach mal ProCall Patchen und den Server neu starten. Das ist sehr frustrierend weil nicht klar ist wo überhaupt das Problem ist, er sucht nur wenn ich das ganze manuell erstelle und ohne Select-Statement arbeite.
<SelectStatement></SelectStatement>
<UseSelectStatement>0</UseSelectStatement>Wenn ich das bei der manuellen Einrichtung mit Select Statement anlege steht in der databases.xml
<SelectStatement>SELECT * FROM dbo.procall</SelectStatement>
<UseSelectStatement>1</UseSelectStatement>Vielleicht habe ich Glück und ich muss tatsächlich einfach mal ProCall Patchen und den Server neu starten. Das ist sehr frustrierend weil nicht klar ist wo überhaupt das Problem ist, er sucht nur wenn ich das ganze manuell erstelle und ohne Select-Statement arbeite.
Hat denn der Benutzer, welcher dem ODBC-Eintrag zugewiesen ist, auch Zugriff auf die View? Nicht, dass das letzten Endes ein doofes Berechtigungsproblem auf dem Datenbankserver ist und du an der total falschen Stelle suchst.
Sonst wäre immer noch die Frage interessant:
Sonst wäre immer noch die Frage interessant:
Wie sieht die Datenquelle in der Auflistung im ProCall-Client aus?
Okay nach einem Neustart ProCall geht es auch mit Select-Statement und manuell angelegt, Nehme ich die Config und packe sie 1:1 mit Select-Statement in die supplied_databeses.xml geht es aber nach wie vor nicht.
Ja der angemeldete Windows Benutzer hat Zugriff. Bei der manuellen Einrichtung klappt das, da sehe ich auch direkt einen Datensatz in der Vorschau.
Ob der Haken bei Telefonbuch gesetzt oder nicht gesetzt ist scheint egal zu sein.
Ich wiederhole mich ungern, aber:
User-DSN und System-DSN sind zwei verschiedene paar Schuhe.
Edit: Dein Bild sieht nach manuell eingerichtet aus. Da würde der User-DSN greifen!
Hat denn der Benutzer, welcher dem ODBC-Eintrag zugewiesen ist, auch Zugriff auf die View? Nicht, dass das letzten Endes ein doofes Berechtigungsproblem auf dem Datenbankserver ist und du an der total falschen Stelle suchst.
User-DSN und System-DSN sind zwei verschiedene paar Schuhe.
Edit: Dein Bild sieht nach manuell eingerichtet aus. Da würde der User-DSN greifen!
Also der User kann sich mit dem System DSN erfolgreich verbinden (Verbindungstest) und ja, er hat Zugriff. Vielleicht raffe ich da auch was nicht aber wenn ich die Konfiguration manuell einrichte hat der angemeldete Benutzer Zugriff und findet Daten. User DSN ist gar nicht eingerichtet. In der databases.xml steht
Jetzt nehme ich die selbe XML Config und verteile sie über den Pfad der in der Registry steht. Wenn ich ProCall als Benutzer starte wird der komplette <ODBC> Teil in meine databases.xml geschrieben. Jetzt werden keine Daten mehr gefunden oder gesucht. Ich gehe natürlich davon aus das hier die Abfrage auch über System DSN mit dem angemeldeten Windows Benutzer erfolgt denn die Abfrage geht, nach meinem Verständnis, vom Client aus mit der Config die ja defacto identisch in der Config steht im Vergleich zu vorher.
<UserName></UserName>
<Password></Password>Jetzt nehme ich die selbe XML Config und verteile sie über den Pfad der in der Registry steht. Wenn ich ProCall als Benutzer starte wird der komplette <ODBC> Teil in meine databases.xml geschrieben. Jetzt werden keine Daten mehr gefunden oder gesucht. Ich gehe natürlich davon aus das hier die Abfrage auch über System DSN mit dem angemeldeten Windows Benutzer erfolgt denn die Abfrage geht, nach meinem Verständnis, vom Client aus mit der Config die ja defacto identisch in der Config steht im Vergleich zu vorher.
Erstelle mal ein Debug-Log vom ProCall-Client und schaue, was er bei der Nutzung der Datenquelle ausgibt. Denke, dass das der Weg ist, der dich weiterbringt. In der aktuellen Version kannst du die Einstellung für das Protokoll unter Über ProCall... und dann Experten-Ansicht >> einstellen und auch aufrufen.
Ich habe mal zusätzlich einen User-DSN angelegt (der aber anders heißen muss, DSN Namen müssen eindeutig sein) und darauf wieder eine maneulle Datenquelle in ProCall eingerichtet - läuft. XML kopiert und geladen - läuft nicht. Interessant ist das ich den DSN zwar beim anlegen auswähle und dort auch angezeigt wird ob System DSN oder User DSN
aber später in der databases.xml in %APPDATA% steht gar kein Name welcher DSN verwendet wird - odd.
Die Debug Log gucke ich mir nachher mal an, erstmal Gebäudewechsel
Die Debug Log gucke ich mir nachher mal an, erstmal Gebäudewechsel
Zitat von @ukulele-7:
aber später in der databases.xml in %APPDATA% steht gar kein Name welcher DSN verwendet wird - odd.
aber später in der databases.xml in %APPDATA% steht gar kein Name welcher DSN verwendet wird - odd.
Das geht aber aus dem Connect-String hervor. 😉
Bei uns sieht der obere Teil übrigens wie folgt aus:
<StandardSearch>0</StandardSearch>
<SearchOnCall>1</SearchOnCall>
<MandantSearch>0</MandantSearch>
<PhoneBookSearch>1</PhoneBookSearch>weil wir es auch unpersonalisierte Datenquellen handhaben.
Benutzt ihr ProCall in Verbindung mit dem MetaDirectory?
Moin @ukulele-7,
hast du mal mit einem anderen Programm wie z.B. Exel geprüft, ob diese ODBC Datenquelle überhaupt funktioniert.
Ist der entsprechende ProCall Client eine 32Bit Anwendung oder eine 64Bit?
Wenn das eine 32Bit Anwendung ist, dann muss die Quelle über "C:\Windows\SysWOW64\odbcad32.exe" eingepflegt werden.
Bei einer 64Bit Anwendung über "C:\Windows\System32\odbcad32.exe".
Beste Grüsse aus BaWü
Alex
Ich habe mal zusätzlich einen User-DSN angelegt (der aber anders heißen muss, DSN Namen müssen eindeutig sein) und darauf wieder eine maneulle Datenquelle in ProCall eingerichtet - läuft. XML kopiert und geladen - läuft nicht. Interessant ist das ich den DSN zwar beim anlegen auswähle und dort auch angezeigt wird ob System DSN oder User DSN
aber später in der databases.xml in %APPDATA% steht gar kein Name welcher DSN verwendet wird - odd.
Die Debug Log gucke ich mir nachher mal an, erstmal Gebäudewechsel
Die Debug Log gucke ich mir nachher mal an, erstmal Gebäudewechsel
hast du mal mit einem anderen Programm wie z.B. Exel geprüft, ob diese ODBC Datenquelle überhaupt funktioniert.
Ist der entsprechende ProCall Client eine 32Bit Anwendung oder eine 64Bit?
Wenn das eine 32Bit Anwendung ist, dann muss die Quelle über "C:\Windows\SysWOW64\odbcad32.exe" eingepflegt werden.
Bei einer 64Bit Anwendung über "C:\Windows\System32\odbcad32.exe".
Beste Grüsse aus BaWü
Alex
Zitat von @Fighter456:
Das geht aber aus dem Connect-String hervor. 😉
Stimmt wohl, war mir erst nicht klar.Zitat von @ukulele-7:
aber später in der databases.xml in %APPDATA% steht gar kein Name welcher DSN verwendet wird - odd.
aber später in der databases.xml in %APPDATA% steht gar kein Name welcher DSN verwendet wird - odd.
Das geht aber aus dem Connect-String hervor. 😉
Benutzt ihr ProCall in Verbindung mit dem MetaDirectory?
Nein, ich hab da ehrlich gesagt noch gar nicht mit gearbeitet. Ich bin auch eher ein SQL Mensch, daher schien mir eine ODBC Anbindung an CRM (was auch nach OL synchronisiert) die logische Wahl.Zitat von @MysticFoxDE:
Moin @ukulele-7,
hast du mal mit einem anderen Programm wie z.B. Exel geprüft, ob diese ODBC Datenquelle überhaupt funktioniert.
Ja habe ich auch noch zusätzlich gemacht obwohl ja auch schon durch ProCall selbst klar war das es funktioniert und Daten liefert.Moin @ukulele-7,
hast du mal mit einem anderen Programm wie z.B. Exel geprüft, ob diese ODBC Datenquelle überhaupt funktioniert.
Ist der entsprechende ProCall Client eine 32Bit Anwendung oder eine 64Bit?
Hier hat mich ProCall etwas fehlgeleitet aber tatsächlich nicht ausschlaggebend. Der Vollständigkeit halber:- Das ProCall Setup spricht von einem 64 Bit Modul. Das hat es auch bei meinem erfolgreichen Update von 6.2.x auf 6.4.x
- Installationsort auf einem neuen System ohne ProCall ist
C:\Program Files (x86)\ESTOS\ProCall\ECtiClient.exe
- Installationsort auf unseren Produktivsystemen ist
C:\Program Files (x86)\ESTOS\ProCall 5\ECtiClient.exe
Für die 6er Versionsnummern gibt es jeweils Unterordner. ESTOS hat hier wohl einen Wechsel vollzogen und die Version aus dem Hauptpfad raus genommen, bei uns ist der Installationsort aber ein Ordner von ProCall 5, es handelt sich aber um Version 6.
- Die ECtiClient.exe ist tatsächlich eine 32 Bit Anwendung. Wiso das Setup von 64 Bit spricht weiß ich nicht, es gibt ein Unterverzeichnis x64.
- Tatsächlich werden nur 32 Bit System DSN zur Einrichtung angeboten, ein 64 Bit DSN wird gar nicht erst angezeigt.
Wenn das eine 32Bit Anwendung ist, dann muss die Quelle über "C:\Windows\SysWOW64\odbcad32.exe" eingepflegt werden.
Bei einer 64Bit Anwendung über "C:\Windows\System32\odbcad32.exe".
Ja das hat sich MS echt fein ausgedacht. 32 Bit DSN ist hier richtig und ProCall ist eigentlich 32 Bit auch wenn es gern was anderes erzählt.Bei einer 64Bit Anwendung über "C:\Windows\System32\odbcad32.exe".
Es funktioniert jetzt, sogar fast immer...
Hier eine ganze Liste von Dingen die ich geändert / gefixt habe die einen Einfluss gehabt haben können:
- Die Debug-Log (danke für den Hinweis) hat tatsächlich Spaltennamen mit Umlauten angemeckert. Normalerweise hätte ich die nie angelegt, beim manuellen Einrichten hat das aber sofort die Zuordnung ersparrt weil ProCall selbst mit Umlauten arbeitet - es schien mir kein Problem. In der Log gab es dann aber Fehler, ich habe auf Umlaute verzichtet wie sich das gehört und die Zuordnung manuell gemacht.
- In der zentralen Config-Datei habe ich
<?xml version="1.0" encoding="utf-8" ?>
am Anfang gesetzt, das war vorher nicht der Fall. Eventuell hätte auch nur das das Umlautproblem gelöst aber sicher ist sicher.
- Ich habe die Config-Datei aus meinem APPDATA kopiert und dann gekürzt und nicht die Config in eine leere Textdatei kopiert.
- Ich habe die alte Config unter APPDATA beim Benutzer grundsätzlich vorher gelöscht.
Jetzt geht es bei bisher drei Benutzern. Interessanter Weise werden beim dritten einge Kontakte nicht gefunden, es gibt aber definitiv die Kontakte aus der Datenquelle und die Daten in der Datenquelle sind auch die selben. Das muss ich beobachten.
Ich habe auch noch eine searchresult.xml verteilt, das dient aber nur der korrekten Anzeige der Kontaktnamen.
Irgendwie habe ich mich zu früh gefreut. Ich habe jetzt zu den drei Leuten wo es geht zwei neue dazu genommen und es geht wieder nicht - ich werd noch irre. Selber RD-SH, selbe Config, selbe Rechte. Bei mir kann ich die config löschen, neu laden und es geht, bei den neuen Benutzern wird einfach kein Datensatz gefunden...
Wenn es bei dir funktioniert, muss bei deinen Kolleginnen und Kollegen ja irgendetwas anders sein. Wir benutzen das GPO-basierte Ausrollen der Konfigurationen seit über einem Jahr mit ProCall 7 und haben keine Probleme. Wir gehen sogar einen Schritt weiter und verteilen sogar den zu verwendenden Benutzernamen und Kennwort (unterschiedlich je Benutzer), da der UCServer nicht mehr der Domäne verbunden ist. Sind dementsprechend sogar benutzerbezogenen GPOs.
Was sagt denn das Debug-Log bei den Personen, wo es nicht funktioniert zum Zeitpunkt der Suche?
Was sagt denn das Debug-Log bei den Personen, wo es nicht funktioniert zum Zeitpunkt der Suche?
Ich glaube diesmal war wirklich SQL schuld, es gab ein Verbindungsproblem. Interessant das es vorher bei mir und anderen lief aber ich glaube das gehört noch auf meine Liste der möglichen Ursachen.
In SQL waren für eine AD Gruppe Connect-Rechte auf die DB und Lese-Rechte auf die Tabelle gesetzt. Die AD Benutzer waren auch Mitglieder der Rechtegruppe nur im SQL Server war kein Login für die AD Gruppe angelegt. Ich vermute ich habe mich anderweitig mit dem SQL Server verbunden (bin auch Mitglied in einer anderen Gruppe mit anderen Rechten und die hat einen Login) daher vermutlich dieses seltsamme Fehlerbild.
Ich werde das durchprügeln bis es läuft.
In SQL waren für eine AD Gruppe Connect-Rechte auf die DB und Lese-Rechte auf die Tabelle gesetzt. Die AD Benutzer waren auch Mitglieder der Rechtegruppe nur im SQL Server war kein Login für die AD Gruppe angelegt. Ich vermute ich habe mich anderweitig mit dem SQL Server verbunden (bin auch Mitglied in einer anderen Gruppe mit anderen Rechten und die hat einen Login) daher vermutlich dieses seltsamme Fehlerbild.
Ich werde das durchprügeln bis es läuft.
