Änderungen in Version 10

Datenbankanpassungen

Beim Öffnen der Solution wird ein Hinweisdialog "Datenbankstruktur muss angepasst werden" angezeigt. Folgen Sie den Anweisungen der Anwendung, um die für die formatierten Notizen notwendige Umwandlungsfunktion zu erzeugen.

Geokodierung

Beim erstmaligen Start von combit CRM werden die zu den Datensätzen (z. B. Firmen und Kontakte) gehörenden Geodaten aufgrund zwingend notwendiger interner Anpassungen gelöscht. Bei der ersten Verwendung einer entsprechenden Funktion (z. B. Umkreissuche oder Landkarte) können diese neu erzeugt werden.

Anzeige von Feldinhalten

WICHTIG! Die Anwendung kann optional den Feldinhalt exakt so anzeigen, wie er auch physikalisch in der Datenbank gespeichert ist. Standardmäßig werden etwaige angehängte Leerzeichen in Zeichenfeldern für die Anzeige und Weiterverarbeitung implizit entfernt. Dies führt allerdings zu unintuitiven Inkonsistenzen zwischen Oberfläche und Filterabfragen, wenn ein Feldinhalt nur aus Leerzeichen besteht oder Leerzeichen angehängt hat: Ein Feld ist augenscheinlich leer, der Datensatz ist aber nicht im Filter "Feld ist leer", gleiches für "endet mit" Bedingung u. ä.).

Durch eine Option in der Projektdatei kann dieses Verhalten geändert werden, indem eine Untersektion namens "ExtendedSettings" erstellt und darin die Option "RecordGetFieldRTrimByDefault" auf 0 gesetzt wird:

...

 <!-- DATA -->

 <profile>

  <list name="">

   <list name="ExtendedSettings">

    <item name="RecordGetFieldRTrimByDefault">0</item>

   </list>

 ...

Dadurch wird zum einen eine o.a. potentielle Inkonsistenz behoben, zum anderen führt dies zu einer Geschwindigkeitsverbesserung, da der Schritt des Entfernens anhängender Leerzeichen entfällt.

ACHTUNG! Wird diese Option aktiviert, so kann es zu geändertem Verhalten z. B. in Eingabemaske oder Druckvorlagen kommen, wenn dort Feldinhalte mit einem festen Wert verglichen werden und jetzt aber infolge anhängender Leerzeichen der Vergleich nicht mehr zutrifft.

Auswirkung bei Microsoft SQL Server: Bei der Verwendung von CHAR-Feldern (also nicht VARCHAR!) führt diese Änderung visuell dazu, dass Feldinhalte mit Leerzeichen auf die maximale Feldlänge aufgefüllt dargestellt werden, da dies physikalisch in der Datenbank tatsächlich so der Fall ist. Hier kann geprüft werden, ob eine Umwandlung dieser Felder in den Feldtyp (n)varchar sinnvoll und machbar ist, und dann nach der Umwandlung weiterhin anhängende Leerzeichen 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;

Ä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: Wird bei einem bestehenden Datensatz per SDK-Schnittstelle (oder anderweitig in der Oberfläche oder bei Import mit Abgleich) gar kein Feld gesetzt und (trotzdem) der Datensatz dann gespeichert (z. B. über Record.Save), so wird jetzt kein UPDATE auf die Datenbank mehr ausgelöst, um unnötige SQL Transaktionen vermeiden. Achtung: Dies bedeutet, dass eine derartige Vorgehensweise, um bspw. absichtlich lediglich den letzten Änderungsbenutzer und das letzte Änderungsdatum zu aktualisieren (und sonst nichts), so nicht mehr funktionieren wird! Für dieses Ergebnis muss explizit ein Feld auf einen Wert, der auch identisch mit dem bereits vorhanden sein kann, gesetzt werden.

▪    Das Ereignis "Eingehender Anruf wurde gesucht" enthält nun im Event-Objekt die neue Eigenschaft "RecordSet". Diese enthält die Treffer und ist Nothing falls keine Treffer gefunden wurden. Dies ERSETZT die Benutzung von WScript.Event.View in diesem Event! Achtung: Der RecordSet ist u. U. nicht-visuell! Das Ereignis-Script wird (NEU!) ASYNCHRON ausgeführt. Über WScript.Event.Cancel=true kann durch das Script das Benachrichtigungsfenster ("Sie erhalten einen Anruf...") geschlossen werden.

▪    Aus Sicherheitsgründen ist der Zugriff auf "ViewConfig"-Objekte von Ansichten, auf die der aktuelle Benutzer keine Zugriffsrechte besitzt, nun nicht mehr möglich. Gleiches betrifft auch "Relation"-Objekte, die auf eine Ansicht zeigen, auf die der Benutzer keine Zugriffsrechte hat. Alle diese ViewConfig- und Relations-Objekte werden in ihren übergeordneten Collections ("ViewConfigs"/"Relations") für die Eigenschaften/Methoden .Count() und .Item() erst gar nicht angeboten, und bei einem versuchten Direktzugriff per .ItemByName() dann kein Objekt zurückgegeben. In letzterem Fall erfolgt eine Fehlerausgabe auf Debwin.

▪    Die Methode "Login" des cRM-Objektes sollte nur aufgerufen werden, wenn noch kein anderes Projekt geladen ist. Sollte bereits ein Projekt geladen sein, wird eine Exception ausgelöst, sofern sich das geladene Projekt vom angegebenen Projekt unterscheidet. Sollte aber das angegebene Projekt das gleiche sein wie das aktuell geladene Projekt, so wird das aktuelle Projekt verwendet und zurückgeliefert. Hierbei werden jedoch der angegebene Benutzername und das Passwort ignoriert und der Benutzer des bereits geladenen Projektes verwendet.

▪    Das Ereignis "Menübefehl wird ausgeführt" erfordert nun (analog zu allen Menübefehlen) das etwaige Beenden des Bearbeiten-Modus (d. h. die Rückfrage nach dem Speichern etwaiger Änderungen) - AUSGENOMMEN die Menüpunkte 'Speichern', 'Speichern & Schließen' und 'Abbrechen'. Wählt der Benutzer bei der Rückfrage "Abbrechen", so wird das Ereignis auch nicht ausgeführt. Allerdings unterstützen die Scripte für diesen Event im Gegenzug nun aber auch <!--#pragma keepeditmode--> und <!--#pragma autosave-->.

▪    Die Methode Record.Lock und die Eigenschaft Record.Editable prüfen nun auch das Ansichtsrecht "Datensatz ändern", bislang wurde ausschließlich das etwaige Datensatzrecht geprüft. Analog prüft die Eigenschaft Record.Deletable nun auch das Ansichtenrecht "Datensatz löschen". Es erfolgt keine visuelle Benachrichtigung! Dies muss das Script übernehmen, falls .Lock/.Delete fehlschlägt. Dies war bislang aber sowieso notwendig, da bei fehlenden Datensatzrechten hier auch keine Meldung ausgegeben wurde.

▪    Die Methoden RecordSet.NewRecord bzw. Record.Delete prüfen das Ansichtsrecht "Datensatz neu anlegen" bzw. "Datensatz löschen" nur noch nicht-visuell, es kommt im Fehlerfall keine Meldung mehr! Das heißt, das Script muss eine visuelle Benachrichtigung übernehmen, falls der Aufruf fehlschlägt. Dies dient der Einheitlichkeit zur Methode Record.Lock und den Eigenschaften Record.Editable und Record.Deletable, sowie um einen nicht-visuellen Prozess (z. B. im E-Mail-Autopilot) zu ermöglichen.

▪    Ansichten-Ereignis "Ansicht wurde geöffnet": Aufgrund von Performance-Optimierungen und verbesserter Reaktivität der Oberfläche muss in diesem Zusammenhang die "gerade aktive Ansicht" nicht zwingend die sein, für die das Ereignis "Ansicht wurde geöffnet" gerade ausgeführt wird. cRM.CurrentProject.ActiveViews.ActiveView liefert NICHT zwangsläufig die betreffende Ansicht zurück, nämlich z. B. dann nicht, wenn beim Programmstart gleichzeitig ein ganzer Schwung zuletzt geöffneter Ansichten wiederhergestellt wird, der Benutzer sehr schnell wieder eine andere Ansicht aktiviert, oder auch die Info-Zentrale und/oder Terminverwaltung gleichzeitig geöffnet wird. Der Zugriff auf das Ansichten-Objekt, in dessen Kontext das Ereignis gerade stattfindet, darf ausschließlich über WScript.Event.View erfolgen.

▪    Die Methoden PrintCard, PrintLabel, PrintReport, Save, SendRecordRef und TransferData des Record Objekts sowie die Methoden Export, PrintCard, PrintLabel und PrintReport des RecordSet Objekts lösen jetzt das zugehörige Autoprotokoll aus, auch wenn es sich um ein nicht-visuelles Record/RecordSet Objekt handelt.

▪    Erreichen die Methoden RecordSet.MoveNext bzw. RecordSet.MovePrevious das Ende bzw. den Anfang des (nicht leeren) RecordSets, so lieferte bislang der anschließende Aufruf von RecordSet.CurrentRecord ein NULL/Nothing Objekt. Jetzt wird ein Record Objekt geliefert, nämlich der letzte bzw. erste Record, auf dem der RecordSet ja (weiterhin) trotz erfolglosem Move "stehengeblieben ist". Bei einem leeren RecordSet wird für .CurrentRecord weiterhin NULL/Nothing zurückgeliefert.

Dokumentenablage per Drag & Drop bei Dateiverweisen

Verhaltensänderung bei der Dokumentenablage im Falle von 'Dateiverweisen': Dateien können nun per Drag & Drop mit der rechten Maustaste in Containern per Kontextmenü entweder kopiert oder nur verknüpft werden. Das Standardverhalten bei linker Maustaste ist nun "Kopieren" (erforderte bislang das gleichzeitige Gedrückthalten der Strg-Taste).

Funktionsdefinitionen

Die Anzahl der zur Verfügung stehenden Funktionsdefinitionen wurde von 30 auf 75 erhöht.

Mailvorlagen

Bisher konnten fälschlicherweise in Mailvorlagen auch Feldaliase für relationale Felder (z. B. FirmenID.Firmen.ID.Firma) verwendet werden. Dies ist nun nicht mehr möglich. In betroffenen Mailvorlagen können diese Felder einfach über den Formelassistent durch den korrekten phys. Feldnamen ersetzt werden (z. B. CompanyID.Firmen.ID.Company).

Menüband-Schaltflächen

Selbst angepasste Menüband-Schaltflächen werden zurückgesetzt, da ansonsten neu eingeführte Schaltflächen/Optionen im Menüband nicht sichtbar wären. Das klassische Menü und selbst definierte Tastaturkommandos sind hiervon nicht betroffen.

Reporting

▪    In Tabellen, in denen die Summe ihrer Spalten breiter ist, als die Breite der Tabelle selbst (vgl. Hinweis im Druckvorlagendesigner im Tabelleninhalt-Dialog: "Hinweis: Tabellenbreite um xx.yy mm zu klein."), wird der "überstehende" Bereich rechts nun einheitlich abgeschnitten. (Dies dürfte ggf. bislang auch schon - aufgrund des Seitenrandes - passiert sein.) Bitte prüfen Sie Ihre Berichte dahingehend, falls hier eine millimetergenaue Exaktheit essentiell ist.

▪    Beim PDF-Export eines Berichtes aus einer bestehenden Berichtsansicht wird, analog zum separaten Vorschau-Dialog, ein erneuter Druck ausgelöst, damit Abhängigkeiten von z. B. LL.OutputDevice korrekt berücksichtigt werden können. Dies führt dazu, dass die betroffenen Datensätze aus der Datenbank neu verarbeitet werden und auch etwaige im Report dargestellte Zeitstempel (bei Verwendung der Today()/Now() Designer-Funktionen) aktualisiert werden.