Datenbankanpassungen
Beim Öffnen der Solution wird ein Hinweisdialog "Datenbankstruktur muss angepasst werden" angezeigt. Folgen Sie den Anweisungen der Anwendung.
Systemvoraussetzungen
▪ Windows 8.1 wird nicht mehr unterstützt, da der Support seitens Microsoft seit dem 10. Januar 2023 eingestellt wurde.
▪ PostgreSQL 9.6 wird nicht mehr unterstützt, da der Support seitens PostgreSQL seit dem 11. November 2021 eingestellt wurde.
▪ Microsoft SQL Server 2008/2008 R2 wird vom Replikationsassistenten nicht mehr unterstützt, da der Support seitens Microsoft seit dem 12. Juli 2022 eingestellt wurde.
▪ Windows Server 2012 und Windows Server 2012 R2 unterstützen nicht die aktuelle Microsoft WebView2 und nicht das aktuelle Chromium Embedded Framework! Ab Oktober 2023 erhält die letzte von diesen Betriebssystemen unterstützte WebView2-Version außerdem auch keine Sicherheitsupdates durch Microsoft mehr (https://learn.microsoft.com/de-de/lifecycle/products/windows-server-2012-r2). Dies bedeutet, dass auf einem Windows Server 2012 und Windows Server 2012 R2 Exchange-Synchronisation, Info-Zentrale, Web-Ansichten, Web-Elemente und das Web-Panel nicht funktionieren. Außerdem stehen Landkarten und OAuth-Authentifizierungsdialoge auf diesen Betriebssystemen nicht zur Verfügung. Es erfolgt an diesen Stellen eine entsprechende Meldung. Die restlichen Programmteile der Anwendung sind nicht betroffen. Es kommt vorerst beim Anwendungsstart daher auch keine Warnung hinsichtlich dieser Betriebssysteme. Dies kann aber für die Zukunft nicht gänzlich ausgeschlossen werden.
Administration
▪ Bei einer Microsoft SQL Server Express Edition wird nun beim Programmstart wieder eine Warnung ausgegeben, wenn die zu Grunde liegende Datenbank 80 % der erlaubten Größe von 10 GB erreicht hat.
Wichtige Änderungen und Neuerungen im SDK
Eine Auflistung aller Neuerungen und Änderungen im SDK finden Sie über die Programmgruppe unter dem Punkt "Programmierer-Referenz" im Dokument "SDK_DE.pdf".
▪ Performance-Verbesserung: ViewConfig.CreateRecordSet, View.CurrentRecordSetCopy, InputFormContainer.CurrentRecordSetCopy, RecordSet.CreateCopy, Record.GetRelationalRecordSet haben nun zusätzlichen optionalen integer Parameter "nCursorModel" zur Spezifikation des Datenbankcursormodells, das für den zurückgegebenen RecordSet genutzt werden soll. Werte 0: default (führt ohne zusätzliche Maßnahme zu cRM11-kompatiblem Verhalten, entspricht auch dem Verhalten, wenn der Parameter weggelassen wird), 1: full-dynamic (entspricht dem Verhalten von Version 11 und älter), 2: forward-only). Die Methoden RecordSet.DialogSelectRecord, RecordSet.DialogSelectRecordMultiple, RecordSet.SendBulkMail, RecordSet.MovePrevious und RecordSet.MoveLast werden einen Scriptfehler werfen, wenn sie für einen forward-only RecordSet aufgerufen werden. RecordSet.MoveFirst nur dann, wenn zwischenzeitlich MoveNext Aufrufe stattgefunden haben.
▪ Performance-Verbesserung: Der Standardwert für das COM-RecordSet-Cursormodell, sofern bei den Methoden ViewConfig.CreateRecordSet, View.CurrentRecordSetCopy, InputFormContainer.CurrentRecordSetCopy, RecordSet.CreateCopy, Record.GetRelationalRecordSet nicht (oder mit 0) angegeben, kann durch eine Option in der Projektdatei vorgegeben werden. Ist dies nicht der Fall, so wird abwärtskompatibles Verhalten zur Version 11 oder früher erzwungen, also 1 (=full-dynamic) angenommen. Mögliche Werte 1: full-dynamic, 2: forward-only.
...
<!-- DATA -->
<profile>
<list name="">
<list name="ExtendedSettings">
<item name="COMRecordSetCursorDefault">2</item>
</list>
...
▪ Verhaltensänderung: Performance-Verbesserung: Die Methoden RecordSet.DialogSelectRecord, RecordSet.DialogSelectRecordMultiple, RecordSet.SendBulkMail (wenn Maileditor dabei angezeigt werden soll) und InputForm.DialogSelectRecordDropDown erfordern einen full-dynamic RecordSet. Anderenfalls werden diese Methoden eine full-dynamic Kopie das RecordSets selbst erzeugen. Dies führt zu einer unnötigen zusätzlichen RecordSet-Erstellung und Datenbankabfrage, die vermieden werden sollte, indem von Anfang an ein entsprechender full-dynamic RecordSet für diese Methoden genutzt wird!
▪ Verhaltensänderung: Der Anwendungstitel wurde geändert von "combit Relationship Manager" auf "combit CRM". Etwaige Makros, die den Fenstertitel verwenden, z. B. WshShell.AppActivate ("combit Relationship Manager -"), müssen angepasst werden.
▪ Verhaltensänderung: C#-Scripting: View.CurrentRecordSetCopy und Container.CurrentRecordSetCopy sind nun Methoden und keine Eigenschaften mehr, daher muss im C# Script die Nutzung von .CurrentRecordSetCopy; auf .CurrentRecordSetCopy(); (=Funktionsaufruf) umgestellt werden.
▪ Verhaltensänderung: Record.SendSingleMail und Record.SendMailDirect stellen keinen Statusfortschrittsdialog für die Zwischenschritte beim Versand dieser einzelnen E-Mail mehr dar ("Verbindung wird aufgebaut." etc.). Bei einem schnellen Versand mehrerer E-Mails wird so unnötiges Flackern vermieden. Scriptprogrammier:innen müssen sich ggf. selbst per cRM.StartWaitDlg um eine Warteanzeige kümmern, sofern die vorgenannten Record.Send... Methoden in einer Schleife und nicht nur für 1 Datensatz genutzt werden.
▪ Verhaltensänderung: Performance-Verbesserung: Record.Lock hat nun einen optionalen Parameter zur Steuerung, ob beim Sperren mit anschließendem Speichern auf Änderungen an den gesetzten Feldern "hinterrücks" durch andere Anwender:innen geprüft und dann das Speichern fehlschlagen soll. Die Voreinstellung ist false (nein), was gerade bei einer Massenverarbeitung von allen Datensätzen eines RecordSet in einer Schleife erhebliche Performancegewinne bringt: in diesem Fall schlägt das Speichern nicht fehl und die zuallerletzt gespeicherte Änderung gewinnt immer. Bei allen vorherigen Programmversionen war das Verhalten implizit immer true (Ja).
▪ Ein Record(Buffered)-Objekt löst nun bei allen Methoden, die nicht für einen RecordBuffered erlaubt sind, einen Scriptfehler aus, sofern der zugrundeliegende RecordSet zwischenzeitlich auf einem anderen Datensatz steht.
▪ Performance-Verbesserung: DialogSelectRecord und DialogSelectRecordMultiple starten nun für einen per ViewConfig.CreateRecordSet erzeugten RecordSet viel schneller (insbesondere, wenn dem RecordSet ein komplexer, "teurer" Filter zugrundeliegt). Wichtig: Bei DialogSelectRecord darf in dem Kontext für den RecordSet keine Move-Methode aufgerufen werden, da sonst der von DialogSelectRecord zurückgegebene Record u. U. seine Werte verändert!
▪ Performance-Verbesserung: Der Hauptspeicherverbrauch von Record.SetContentsByNameFromFile wurde - vor allem im Fall von großen Dateien - minimiert. WICHTIG! Potentielle Verhaltensänderung! Diese Optimierung setzt nun zwingend voraus, dass die angegebene Datei zum Zeitpunkt des anschließenden Record.Save Aufrufes noch am angegebenen Pfad zu finden ist. Sie darf erst danach gelöscht/überschrieben werden.
▪ Neue SDK Methode cRM.DialogAddressAssistant(nMode, sInputAddress): bei einer etwaigen sInputAddress werden die Bestandteile TAB-separiert ('\t' / Chr(9) / vbTab) in der Form "Land\tOrt\tPLZ\tStraße\tHausnummer" erwartet. Nicht vorhandene Adressteile können zwischen den TABs leergelassen werden; wird die Hausnummer nicht separat vom Straßenfeld geführt, dann kann der Hausnummernteil leergelassen und die Hausnummer zusammen mit der Straße übergeben werden. Wichtig: Die Angabe des Landes gemäß der Länderkonfiguration in den Ansichteneigenschaften ist obligatorisch. nMode=0: der Adresseingabeassistent wird auf jeden Fall angezeigt, 1: der Adresseingabeassistent wird lediglich bei unvollständiger und mehrdeutiger Adresse angezeigt, ansonsten werden fehlende Bestandteile ohne weitere Interaktion stillschweigend aufgefüllt zurückgegeben. Rückgabewert: "$CANCEL$" bei Abbruch, ansonsten die eingegebene/vervollständigte Adresse mit folgenden TAB-separierten Bestandteilen: "Land\tOrt\tPLZ\tStraße\tHausnummer\tVorwahl\tBundesland/Kanton\tRegierungsbezirk\tLandkreis". Die Ortsvorwahl hängt stark von der Verfügbarkeit im Datenbestand ab. Bei zukünftigen Erweiterungen können weitere Ergebnisse per TAB getrennt angehängt werden, daher ist es unerlässlich die Teile von Anfang an genau zu splitten, d. h. Landkreis = "Teil-String vom 8. TAB bis zum 9. TAB, sofern vorhanden, sonst bis Zeichenkettenende" anstatt "alles rechts vom 8. TAB".
▪ Verhaltensänderung: Performance-Verbesserung: Wird ein cRM-Objekt per CreateObject erzeugt und danach cRM.Login durchgeführt, so werden nun nicht mehr die zuletzt geladenen Ansichtenfenster wiederhergestellt, da die Instanz in jedem Fall unsichtbar ist. Ist die Wiederherstellung der zuletzt geladenen Ansichtenfenster aus bestimmten Grund unbedingt erwünscht, dann muss vor dem Aufruf von cRM.Login die Eigenschaft cRM.Visible=True gesetzt werden.
▪ (Potentielle) Verhaltensänderung: Alle HTTP-Anfrage-Methoden: Enthielt die übergebene URL einen Port im Format http[s]://<host>:<port>, dann konnte weder der Host noch der Port korrekt ausgelesen werden. Außerdem werden Anfragen, die mit http beginnen und keinen oder einen anderen Port als 443 angeben, nun korrekt ohne SSL/TLS zu nutzen verarbeitet.
▪ Verhaltensänderung: Alle HTTP-Anfrage-Methoden: Es sind nun ausschließlich URLs erlaubt, welche mit http[s]:// beginnen. Beginnt eine URL nicht damit, wird ein entsprechender Fehler zurückgegeben.
Sonstige wichtige Änderungen und Hinweise
EXEC sp_configure 'show advanced options', 1
reconfigure
EXEC sp_configure 'disallow results from triggers', 1
reconfigure
EXEC sp_configure 'show advanced options', 0
reconfigure
▪ Das Menüband (Ribbon) analog zu Microsoft Office ist nun Standard. Das alte klassische Menü wird nicht mehr unterstützt.
▪ Verhaltensänderung: Bereits entpackte Geo-Datenbanken werden nun nicht mehr im Installationsverzeichnis gesucht, sondern werden im Installationsverzeichnis im Unterverzeichnis "Directories" gesucht.
▪ Verhaltensänderung: Um die Datenbankstruktur bzw. Tabellenstruktur innerhalb des Projekts bearbeiten zu dürfen, sind nun keine kompletten Administratorenrechte mehr erforderlich, sondern lediglich die Rechte "Projektkonfiguration ändern" und "Ansicht konfigurieren" müssen gewährt sein.
▪ Um ein zeitnahes Stoppen eines Workflow-Servers (ggf. als Dienst) zu gewährleisten, sollten Scripte mit einer potentiell längeren Ausführzeit unbedingt regelmäßig im Scriptverlauf die WScript.Terminate Eigenschaft prüfen und im Falle von true die Scriptausführung beenden.
▪ Verhaltensänderung: Der Klick auf den Hinweis im Infobereich der Taskleiste bei eingehendem Anruf bringt nun das Hauptfenster auf jeden Fall in den Vordergrund.
▪ Verhaltensänderung: Das relationale Ergänzen berücksichtigt ebenfalls etwaige Feldvorbelegungsformeln. Falls diese Formeln datensatzspezifische Feldnamen enthalten, führt dies dazu, dass der relationale Ergänzen-Vorgang dann nicht (mehr) serverseitig durchgeführt werden kann, wie dies evtl. vorher ohne die Feldvorbelegung der Fall gewesen wäre. Um dies zu umgehen, werden alle Felder, die beim relationalen Ergänzen aufgeführt werden, in jedem Fall prioritär vor ihrer etwaigen Vorbelegungseinstellung behandelt. D. h. ein eigentlich mit einer Feldformel vorbelegtes Feld kann über die Feldliste beim relationalen Ergänzen auf einen festen Wert (auch leer) gesetzt werden, so dass die eigentliche Vorbelegung nicht greift und somit dann auch ggf. weiterhin eine serverseitige Ausführung möglich ist.
▪ Verhaltensänderung: Die Anwendung wird nun bei zu speichernden Inhalten von Zeichenfeldern automatisch etwaige am Ende befindlichen Leerzeichen (32, 160, U8201, U8239)/Tabulatorzeichen/Zeilenumbrüche (letztere nur sofern kein Notizfeld) entfernen. Die Voreinstellung ist AN. Auswirkung bei Microsoft SQL Server: Bei der Verwendung von (N)CHAR-Feldern (also NICHT VARchar) hat diese Änderung keinen Effekt, da diese Felder physikalisch in der Datenbank mit Leerzeichen aufgefüllt werden. Wir empfehlen, diese Felder in den Feldtyp (n)varchar umzuwandeln und die auch nach der Umwandlung weiterhin anhängenden Leerzeichen dann einmalig zu entfernen: UPDATE "Tabellenname" SET "BetroffenesFeld" = RTRIM("BetroffenesFeld"). Folgende Abfrage liefert die potentiell betroffenen Tabellenspalten: SELECT COLUMN_NAME, TABLE_SCHEMA, TABLE_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH FROM INFORMATION_SCHEMA.COLUMNS WHERE DATA_TYPE IN( 'Char', 'nchar' ) ORDER BY TABLE_NAME ASC, COLUMN_NAME ASC;. Durch eine Option in der Projektdatei kann dieses Verhalten geändert werden, indem eine Untersektion namens "ExtendedSettings" erstellt und darin die Option "RecordSetFieldRTrimByDefault" auf 0 gesetzt wird:
<!-- DATA -->
<profile>
<list name="">
<list name="ExtendedSettings">
<item name="RecordSetFieldRTrimByDefault">0</item>
</list>
...
▪ Verhaltensänderung: Die Anwendung wird nun bei zu speichernden Inhalten von Zeichenfeldern automatisch das Feld bei leerem Inhalt ("") auf NULL setzen (anstatt auf Leer ""). Die Voreinstellung ist AN. Dadurch ergibt sich ein einheitlicher Feldinhalt (NULL) sowohl bei der Neuanlage eines Datensatzes als auch bei einem nachträglich geleerten Feldinhalt. Dadurch greifen jetzt überhaupt auch erst "NOT-NULL" Constraints einheitlich auch bei einem nachträglichen Leeren eines Zeichenfeldes. Durch eine Option in der Projektdatei kann dieses Verhalten geändert werden, indem eine Untersektion namens "ExtendedSettings" erstellt und darin die Option "RecordSetEmptyFieldToNullByDefault" auf 0 gesetzt wird:
<!-- DATA -->
<profile>
<list name="">
<list name="ExtendedSettings">
<item name="RecordSetEmptyFieldToNullByDefault">0</item>
</list>
...
▪ Verhaltensänderung: Felder vom internen Typ "Datum" ohne Uhrzeitanteil haben nun auch in Berichten und Formlen keinen Uhrzeitanteil mehr, selbst wenn physikalisch einer im Datensatz vorhanden sein sollte, z. B. wenn das Feld physikalisch in der Datenbank ein DatumZeit-Feldtyp ist und z. B. per Datenbanktrigger inklusive Uhrzeitanteil befüllt wird.
▪ Verhaltensänderung: E-Mail-Tool CleverReach: Neu erstellte E-Mailings werden jetzt automatisch mit dem neuen CleverReach-Maileditor V2 erstellt und bearbeitet. Bereits mit dem bisherigen klassischen Maileditor erstellte E-Mailings werden automatisch weiterhin mit dem bisherigen Maileditor geöffnet. Soll auch für neue E-Mailings nicht der neue, sondern weiterhin der alte Maileditor verwendet werden, muss in den Verbindungsdaten des E-Mail-Tools in den Projekteinstellungen der Solution explizit die Zeile "Editor: Classic" hinzugefügt werden.
▪ Verhaltensänderung: E-Mail-Tool Inxmail: Beim Löschen von Teilnehmern von einer Liste wurden diese bislang nach entsprechender Sicherheitswarnung in Inxmail global entfernt, d. h. von allen Listen. Jetzt werden diese Teilnehmer nicht mehr von allen Listen entfernt, sondern nur noch von dieser spezifischen Liste.
▪ Verhaltensänderung: Nachrichten Add-in: War die Option aktiviert, dass ein neuer Datensatz in der Suchansicht automatisch erstellt werden sollte, sofern kein Suchtreffer erzielt werden konnte, so wird nun ausschließlich das erste physikalische Feld vom internen Typen "E-Mail" mit dem Inhalt der E-Mail-Adresse geschrieben und nicht mehr alle. Zusätzliche Felder können weiterhin über die Feldvorbelegung konfiguriert werden.