Hallo zusammen,
Ich möchte einen einzelnen Datensatz aus einer anderen Solution importieren, die auf einem anderen Server im gleichen Netzwerk liegt. ODBC-Verbindung besteht. Wie definiere ich im Assistenten für den Daten-Import mit Abgleich den einzelnen zu importierenden Datensatz?
Auch eine umgekehrte Lösung wäre vorstellbar, in der ich den Datensatz aus der anderen Solution exportiere.
Wie kann ich da ansetzen?
Hallo Herr Klöskes,
warum so kompliziert?
Wenn es sich doch nur um einen Datensatz handelt, kann man den doch sicherlich filtern und über den Export-Assistenten den in eine *.csv - Datei oder eine Excel-Datei exportieren.
Im zweiten Schritt den Datensatz in der neuen Solution über Import/Abgleichen den Datensatz ganz einfach importieren/abgleichen. Hierfür braucht man keine ODBC-Verbindung.
Beste Grüße
Frank Wietzel
Hallo Herr Wietzel,
diese Option ist für den Anwender zu kompliziert. Das muss quasi per Knopfdruck geschehen. Klicken, andere Solution öffnen und der Datensatz ist da.
Beste Grüße aus dem ziemlich kalten Nettetal.
Dass Sie eine dauerhafte Lösung brauchen, mit der Endanwender:innen dauerhaft/wiederholend klarkommen sollen, wurde aus Ihrem O-Posting ganz klar. (Ich hatte auch gedacht, dass Sie jetzt halt ausnahmsweise 1 Datensatz aus einer eigentlich schon lange in Rente geschickten Solution doch noch brauchen.)
Dann ist vermutlich auch kein Import-/Abgleich Assistent praktikabel.
Meine Lösung für den Assistent wäre (vor Ihrer letzten Antwort) gewesen, dass Sie hier
Wenn Sie das jetzt aber als dauerhaften „Teil“ Ihres cRM Betriebs realisieren wollen, dann muss da eine bessere Lösung her. 
Können Sie daher noch ein wenig ausholen? Was ist denn genau der Hintergrund?
Dann fällt uns bestimmt noch was ein.
Das mit dem Datenfilter hatte ich schon probiert, da ich aber dann darauf hingewiesen wurde, dass jetzt 48.600 Datensätze importiert würden, hielt ich den Ansatz für falsch und habe den Vorgang abgebrochen. Sie haben mir jetzt zumindest erklärt, wie der Vorgang abläuft, dass erst der Client die Auswahl trifft. Deswegen auch die Idee des Exportes. Da kann ich zuerst die Auswahl treffen und dann die Auswahl exportieren. Am Besten wäre es, von der einen Solution aus, den betreffenden Datensatz direkt in die andere Solution zu schreiben. Deswegen kam ich auf ODBC. Vielleicht geht so etwas auch über Verbindungsserver und man kann ein Script schreiben, das den Vorgang ausführt, aber daran hab ich mich bisher nicht gewagt. Ich bin auch nicht Der MS-SQL-Experte. Wie die Datensatz-ID letztendlich erzeugt wird, entzieht sich meiner Kenntnis, da wissen Sie besser Bescheid. Ich weiß nicht, ob es möglich sein kann, wenn ich Datensätze in verschiedenen Solutions anlege, ob sich da die Datensatz-ID wiederholen kann. Ausführlicher erläutern könnte man dies vielleicht in einem Telefonat.
Deswegen auch die Idee des Exportes. Da kann ich zuerst die Auswahl treffen und dann die Auswahl exportieren.
Da mit dem Wechsel in die „andere“ Solution auch ein Datenbankserver-Wechsel einhergehen müsste, halte ich das nicht für besonders komfortabel für die Anwender:innen. (Wenn Sie diesen Ansatz dennoch verfolgen möchten, also dass Anwender:innen Solutions auf einem anderen Server mit combit CRM öffnen, dann müssen Sie für den anderen Server in jedem Fall eigene cRM Lizenzen erwerben. Lizenzen für ein Test-/Staging System sind in der Enterprise Edition - ich habe nicht nachgesehen welche Edition Sie haben - zwar bereits enthalten, aber es würde sich hier ja um kein Test-/Staging System handeln.)
Meine Lösung sähe wir folgt aus (nur ein Vorschlag von vielen möglichen)
Ich würde die Tabelle mit den 45.000 potentiell in Frage kommenden Datensätzen einmalig in Ihre jetzige Solution und jetzigen Server übertragen (z.B: per SQL Server Management Studio) und zwar unter einem „sprechenden“ Tabellennamen („Kontakte_alt“, „Kontakte_Archiv“ was auch immer den Inhalt adäquat beschreibt). Dann sind Sie schonmal im „heimischen Universum“. 
Dann können Sie sich eine Ansicht auf diese Tabelle im cRM einrichten (die vielleicht auch nicht jeder sehen können braucht).
Und dann können Sie sich z.B. ein Script schreiben, das die Anwender:innen per DialogSelectRecord(Multiple) aus dieser Ansicht einen/mehrere Datensatz/Datensätze auswählen lässt, und dann per NewRecord in der Zielansicht einen neuen Datensatz erzeugt und dort die zu übernehmenden Quellfelder per GetContentsValueByName ausgelesenen Felder mittels SetContentsValueByName in die richtigen Zielfelder schiebt und den Datensatz dann speichert.
Das wäre dann eine komfortable End-Anwender:innen taugliche Lösung. Und sie käme auch mit evtl. zwischenzeitlich gegenüber der Quelle geänderten Zielfeld-Feldnamen klar. 
Wenn wir lieber möchten, dass wir solch eine Lösung für Sie erstellen, dürfen Sie sich selbstverständlich gerne bei uns direkt melden. 
Mir als Leser ist noch nicht ganz klar welchem Zweck das ganze dient.
Handelt es sich hier um eine Konstelation alter Server mit alter Solution und alten Daten und neuer Server mit neuer Solution (gleiche Tabelle, gleiche Spalten?) und neue Daten in die alte Daten „einzeln“ aber immer mal wieder übernommen werden sollen? Oder geht es wirklich nur um einen Datensatz der immer syncrhon bleiben soll?
Man kann mit einem Verbindungsserver und einem Trigger in MSSQL arbeiten, damit läßt sich eigentlich alles realisieren. Aber ohne klare Zielsetzung kann man auch mögliche Probleme nicht sehen. Was wenn ein Datensatz z.B. in der neuen DB schon existiert? Kann das vorkommen?
Warum nicht eventuell eine Übernahme und Markierung aller Datensätze aus der alten DB in die Neue? Wäre für den Benutzer eventuell leichter.
die Konstellation alter Server mit alter Solution und alten Daten und neuer Server mit neuer Solution (gleiche Tabelle, gleiche Spalten?) ist schon richtig. Am Tag X sollen die meisten Daten in die neue Soltution übertragen werden. Dies würde ich auch über eine CSV-Datei bewerkstelligen wollen. Allerdings müssen einige Kunden aus verwaltungstechnischen Gründen (gebuchtes Seminar | Seminar hat noch nicht stattgefunden | Rechnung noch nicht bezahlt) noch in der alten Solution verbleiben bis der Verwaltungsvorgang abgeschlossen sind. Dann kann der Kunde samt Aktivitäten und anderen Nebentabellen in die neue Solution umziehen und wird in der alten Solution gelöscht. Dies ist aber bei allen in der alten Solution noch verbliebenen Kunden zu einem anderen Zeitpunkt. Neue Datensätze würden grundsätzlich in der neuen Solution angelegt. Wenn alle Kunden umgezogen sind, wird die alte Solution nicht mehr gebraucht und kann in die Tonne. Mit Triggern kenne ich mich nicht aus, könnte mir aber vorstellen, das man für den Umzug in der alten Datenbank ein Häkchen setzen könnte, das einmal am Tag abgefragt wird und die entsprechenden Daten überträgt.
Irgendwer müsste den „Verwaltungsvorgang“ in der Solution also „abschließen“ und ggf. auch den Haken setzen. Daher muss ich nochmal folgende zwei Punkte anbringen:
Lösung:
Schieben Sie die Solution-Datenbank auf Ihren neuen Server, dann haben Sie das Lizenzthema von der Backe, sonst müssten Sie sich bitte wg. zusätzlicher Lizenzen (abhängig davon, wie viele Anwender:innen die Solution auf dem alten Server gleichzeitig nutzen werden) bei uns kurz melden. Dankeschön. 
Gleichzeitig haben Sie den ständigen Server-Wechsel vom Tisch. Ein Server-Wechsel führt auch zu einem cRM_System Datenbankwechsel (da anderer Server) und will u.U. daher einen Anwendungsneustart. Und beim nächsten Neustart ist dann ja (weiterhin) der alte Server noch eingestellt, obwohl der:die Anwender:in aber da gar nicht hin wollte, sondern - wie üblich - eigentlich die neue Solution, womit er:sie in einen Fehler läuft, weil diese Solution auf dem alten Server ja nicht gefunden wird. Das wird meiner Erfahrung nach zu Akzeptanzprobleme Ihres „Updates“ führen und Ihnen zusätzliche „Erklärungsarbeit“ machen. Wenn Sie auf demselben Server sind, dann ist es einfach das Laden einer anderen ‚.cRM‘ Datei. Fertig. 
Und über eine geplante Aufgabe (direkt per SQL via SQL Server Agent oder aber auch per Windows Aufgabe und einem Script) könnten Sie nachts alle noch nicht migrierten Datensätze, die den Haken gesetzt haben, aus Datenbank_alt in Datenbank_aktuell kopieren und in Datenbank_alt als „migriert“ markieren. Fertig.
Also einen Serverwechsel durch den Benutzer kann man umsetzen, ich habe das auch schon gemacht mit einer kleinen bat-Datei die den Registry-Schlüssel für die Datenank (glaube ich) geändert hat und dann konnte man direkt die andere Solution starten.
Um Daten ganz oder teilweise syncrhon zu halten kann man theoretisch alles in der DB bauen aber das ist ein enormer Aufwand verbunden mit möglichen Problemen. Ich würde die ganze Vorgehensweise hinterfragen, also warum nicht alle Kunden und Buchungen am Tag X übernehmen - das müsste eigentlich der bessere Weg sein.
