Datenbankfelder säubern

Forum
1

Vorab, ich bin von combitCRM von Tag zu Tag begeisterter. Das System bietet so viele Möglichkeiten für Eigenentwicklungen, dass man eine Menge an Exceltabellen ablösen kann.

So baut man neue Ansichten auf, verknüpft dies mit vorhandenen etc. Dadurch werden immer wieder neue ID-Felder angelegt, damit die Relationen angelegt werden.

Problem: Wenn es doch nicht so klappt, wie gedacht und man neue Ansichten wieder verwirft, kann es sein, dass in den einzelnen Datentabellen Felder sind, die gar nicht mehr benötigt werden, sozusagen „verwaist“ sind. Darüber den Überblick zu behalten, ist nicht einfach.

Gibt es eine Möglichkeit in combitCRM, solche unbenutzten Felder aufzuspüren?

Gruß aus der Oberlausitz

2

Das freut uns natürlich mächtig! :heart_eyes:

Verwaiste Felder: Leider nicht als simples „single click“-Feature.

Das liegt daran, dass wenn irgendein Scriptquellcode auf irgendeiner Serverfreigabe rumliegt und darin auf dieses Feld zugegriffen wird, es dann ein Problem gibt, wenn wir behaupten, dieses Feld sei verwaist, weil wir keine Kenntnis von dieser Scriptdatei haben.

Außerdem gibt es Lösungen, die dies Felder „hinterrücks“ befüllen/benötigen, um zum Beispiel in heterogenen Umgebungen Drittsysteme anzubinden bzw. eine Beziehung zu dortigen Daten herzustellen. Aus combit CRM-Sicht ist diese Feld eigentlich gar nicht wirklich „im Spiel“. Aber dennoch essentiell.

Dann gibt es noch Felder, die wichtig sind, aber visuell/interaktiv nie eine Rolle spielen, sondern nur in irgendwelchen ausgeklügelten freien SQL-Abfragefiltern.

Und so weiter…

Um die Hosen runterzulassen: wir kriegen das einfach nicht wasserdicht hin. Und wenn es nicht wasserdicht ist, dann lieber sagen, dass wir es nicht wissen, als so eine „recht wahrscheinlich aber ohne Gewähr“-Aussage, von der Sie sich dann bei Irrtum nichts kaufen können, wenn das Feld dann weg ist und doch gebraucht wird.

Was Sie machen könnten:

Folgende Abfrage liefert Ihnen eine Liste der Felder einer bestimmten Tabelle (hier: „Contacts“) sortiert nach der Anzahl unterschiedlicher Inhalte. Unter der Annahme, dass Test-Felder nicht gefüllt sind, weil sie gar nicht zum Leben erwachten, könnten Sie hier zumindest potentielle Kandidaten zuoberst in der Liste finden. :nerd_face:

DECLARE @sql NVARCHAR(MAX) = N'';
SELECT @sql = @sql + 
'SELECT ''' + COLUMN_NAME + ''' AS ColumnName, COUNT(DISTINCT CASE WHEN ' + QUOTENAME(COLUMN_NAME) + ' IS NOT NULL THEN ' + QUOTENAME(COLUMN_NAME) + ' END) AS DistinctCount FROM Contacts UNION ALL ' 
FROM INFORMATION_SCHEMA.COLUMNS 
WHERE TABLE_NAME = 'Contacts'

SET @sql = LEFT(@sql, LEN(@sql) - 10);
SET @sql = @sql + ' order by "DistinctCount"'

EXEC sp_executesql @sql;
3

Dankeschön,

dann wohl am besten immer Dokumentieren und dann schnell löschen, wenn man merkt, dass ein Feld nicht benötigt wird.

4

Eine Möglichkeit wäre noch, das Feld / die Spalte in der Datenbank einfach umzubenennen, also z.B. ein Präfix voranstellen.

Als erstes wird die Datenbank meckern wenn irgendwelche Referenzen, Constraints oder dergleichen darauf zeigen. Als zweites würden Trigger oder SPs fehlschlagen, das gibt dann auch noch eine Datenbankmeldung - aus denen geht auch hervor wo das Problem liegt.

Beim Aufrufen von Masken in Combit wird dann auch gemeckert, falls ein solches Feld irgendwo eingeblendet wurde.

5

:+1: Den Tipp :point_up: möchte ich grundsätzlich unbedingt empfehlen. Anstatt ein Feld, eine Datei oder einen Registrykey zu löschen, würde ich ihn immer „erstmal“ nur umbenennen (ich persönlich stelle einen ‚_‘ voran, so dass diese „Lösch“-Einträge/-Dateien immer alphabetisch ganz vorne auftauchen), damit kann man immer noch jederzeit wieder „zurück“.

Das pot. Problem dabei ist z. B. ein erfolgreich seit Jahrzehnten funktionierendes (und schon mehrfach „vererbtes“) Script, das sich eventuell nicht mit Fehlerhandling hinsichtlich des Rückgabewertes der Record.Save-Methode „aufhält“. Dadurch fällt der Datenbankfehler (und die Datensatz-Änderung bzw -Neuanlage) unter den Tisch, bis sich irgendwer irgendwann* mal fragt, wo eigentlich (z. B.) die ganzen Seminaranmeldungen der letzten Wochen geblieben sind.

*) meistens sehr spät, wenn das Ergebnis nämlich eskaliert

Aber auch eine („vorbildlich“) per MsgBox vorgesehene Fehlermeldung (die noch nie zum Tragen kam - bis jetzt) kann Probleme bereiten, wenn diese Script zwischenzeitlich im Kontext vom Workflow-Server, E-Mail-Autopilot-Dienst oder nächtlichen Windows-Aufgabenplanungen auch genutzt wird: das Script steht dann unbeaufsichtigt rum und wartet auf eine OK-Klick, der dort nicht kommen wird.

Mag jetzt übertrieben konstruiert vorkommen, ist es aber nicht, wir haben combit-intern auch bei unseren Solution-Aktivitäten schon so manches Lehrgeld bezahlt.:grimacing: Hinzu kommt noch ein gewisses Maß an combit-Support-Paranoia. :face_with_peeking_eye: