SQL Suche funktioniert nicht

Hallo Andreas,

das Thema SQL ist recht komplex und so mitten drin anzufangen ist da schwierig.
Ich würde die gesamte SQL Geschichte nochmal rausschmeißen und von vorne anfangen.

Vielleicht liegts aber auch an eurem Dateisystem bzw. der David Struktur. Vielleicht sind hier schon defekte oder fehlerhafte Verweise drin die zu diesem Effekt führen.

Denke die Fehlersuche hier übers Forum wird recht schwierig sein.

Welcher Pfad wird denn in den Eigenschaften der gefundenen Nachrichten angezeigt. Ist das der richtige Pfad?

Gruß Jens

Hallo Andreas,

ich glaube nicht, dass diese Infos gehütet werden, sondern eher, dass die Supporter da gar nicht so tief im Thema sind und nur die Entwickler dazu was sagen könnten.

Die DB wird nur zur Suche genutzt und dann im Client vermutlich eine Art Verknüpfung zur "echten" Datei angezeigt. Aber genau weiß ich es auch nicht.
Man kann aber davon ausgehen, dass der Server hierfür keine temporären Dateien erzeugt, das ist bei der klassischen Suche auch nicht notwendig gewesen. Es wird wohl eher eine Art Abbild einer archive.dat im Speicher sein oder sowas.

Du schreibst, dass Du nicht an einen Strukturfehler glaubst. Was ist denn Deine Vermutung?

Zum eingrenzen Fallen mir spontan noch 2 Möglichkeiten ein:
1. Ordner Archvive auf Fileebene umbenennen und durch neustart des SL neu erzeugen lassen (man sollte natürlich vorher dafür sorgen, dass keine Mails empfangen werden und keine User einloggen).
Dann ein paar Beispieldaten erzeugen und die Datenbank zurücksetzen.

2. Neue Davidinstallation auf einem Testsystem, Beispieldaten erzeugen und testen. Wenn es dann geht, dann mal das "echte" Archive-Verzeichnis einhängen und DB erneut zurücksetzen.

Gruß Jens

Hallo Andreas,

wenn das Problem nicht an der Archivstruktur liegen sollte, wäre es zwangsläufig ein systembedingtes Problem, da die SQL Suche generell funktioniert. D.h. letztlich muss es dann irgendwo am Betriebssystem bzw. der Systemumgebung oder dem SQL selbst liegen.

Ich glaube auch, dass man früher oder später eine Lösung finden würde, nur kann ich natürlich nicht einschätzen, wie lange das dauern würde.

Meine Vorschläge zum eingrenzen sind ziemlich schnell durchgeführt. Dafür sollte man nicht länger als 1-1 1/2 Std. brauchen, sofern der Server nicht 5 Jahre alt ist und die SQL Installation ewigkeiten dauert (auf einem modernen Xeon Quadcore läuft die Installation in unter 20 Minuten durch).

Zu Deiner Frage: Ja, gibt es, hängt aber wie immer im Leben von Person und Thema ab. Soweit ich weiß ist der Support auch gestaffelt für TAR, TPP und TSPs.

Gruß Jens

Hallo Andreas,

danke für den Hinweis auf die Suchergebnisse. Hatte ich auch noch nicht entdeckt.

Die Frage ist, ob diese Informationen im Volltext der SQL vollständig sind (nicht in der DB selbst). Bin aber auch nicht sicher wie das mit dem Volltext bei der SQL funktioniert, daher weiß ich auch nicht, wie man das prüfen könnte.

Ob der Volltext existiert kann man mit folgender Abfrage testen (aber der wird da sein, sonst hättest Du vermutlich gar keine Ergebnisse):

SELECT
FULLTEXTCATALOGPROPERTY(cat.name,'ItemCount') as ItemCount,
FULLTEXTCATALOGPROPERTY(cat.name,'MergeStatus') as MergeStatus,
FULLTEXTCATALOGPROPERTY(cat.name,'PopulateCompletionAge') as PopulateCompletionAge,
FULLTEXTCATALOGPROPERTY(cat.name,'PopulateStatus') as PopulateStatus,
FULLTEXTCATALOGPROPERTY(cat.name,'ImportStatus') as ImportStatus
FROM sys.fulltext_catalogs AS cat

Hier sollte eine Zeile zurückgegeben werden, bei uns sind nur zwei Felder gefüllt, ich glaube ItemCount und PopulateStatus.

Übrigens haben wir erst gestern wieder einen Fall gehabt, bei dem durch die Neuinstallation des SQL Servers die Suche funktionierte (vorher hatte er immer Null Ergebnisse obwohl es Einträge in der DB gab - die obige Anweisung hat aber keine Zeile zurückgegeben, also war kein Volltext da).

Gruß Jens

Wieso macht Ihr es Euch so kompliziert? Es gibt nur einen Fulltext Index auf der Tabelle msg der die Spalten AnsiBodyText, BodyText, srFrom, srSubject und srTo beinhaltet. Ob der Index definiert ist, oder nicht könnt Ihr einfach mit dem Microsoft SQL Server Management Studio abfragen. Das ist kostenlos und schneller installiert als der SQL Server. Dann links die Datenbank David Archive Database expandieren und rechtsklick auf der Tabelle msg. Im PopMenu den Punkt Volltextindex öffnen und wenn da Properties auswählbar ist, ist der Index auch definiert.

Aktivieren geht dann per SQL. Ist viel schneller als den ganzen Server neu aufsetzen. Falls der Fulltext Index bereits definiert wurde bekommt man lediglich eine Fehlermeldung. Kaputtmachen könnt Ihr nix.

USE [David Archive Database];
GO
CREATE FULLTEXT INDEX ON msg
(
AnsiBodyText Language 1031,
BodyText Language 1031,
srFrom Language 1031,
srSubject Language 1031,
srTo Language 1031
)
KEY INDEX PK_msg;
GO

Hi Björn,

und was ist, wenn die Erstellung des Volltextindex aufgrund von Berechtigungsproblemen angehalten wurde...?
Das ist nämlich meistens der Fall wie ich jetzt festgestellt habe. Dann hilft die erneute Erstellung des Index vermutlich nichts.

Gruß Jens

Klar, ist richtig. Mir ging es erstmal nur um den Fulltext Index. Da muss man nicht den SQL Server neu installieren. Was für Berechtigungsprobleme meinst Du? So wie ich das sehe wird da nicht viel gemacht.

Z.B. wenn der Fulltext Daemon unter der falschen Anmeldung läuft.

Stimmt. Das kann dann nicht klappen. Die Dienste Microsoft Full-Text Engine for SQL Server (MSFTESQL) und Microsoft SQL Server (MSSQLSERVER) müssen dasselbe Konto verwenden. Allerdings gilt das nur für SQL Server 2005.

Ab SQL Server 2008 läuft auch die Volltextsuche im Dienst MSSQLSERVER. Hier ist es nur erforderlich das ein sogenannter Full-Text Catalog definiert wird.

Nein, ist so nicht korrekt. Es gibt auch bei 2008 immer noch den Fulltextdaemon un der steht standardmäßig auf NTAuthority\Networkservice oder irgendwie sowas. Und das klappt in der Regel nicht.

Wo kann man das Ändern mit der Anmeldung? Vermute, dass unser Kunde auch das Problem hat, da die Suche unvollständig ist.
Bei der Indexierung bleibt im Statusmonitor bei "Waiting stehen" und gibt einen Pfad aus. Dies ist aber nicht der letzte im System sondern irgendwo mittendrin.

Hallo,

Windows Dienste.
Wird hier aber nichts bringen, wenn Daten indexiert werden. Wenn die Anmeldung nicht passt, wird gar nichts indexiert und nichts gefunden.
Dass der Pfad nicht der letzte im System ist hat nichts zu sagen.

Bitte mal prüfen, ob bei bestimmten Ordner die Indexierung unterbunden ist, bzw. ob die Eigenschaft Ausblenden gesetzt ist. In beiden Fällen werden die entsprechenden Ordner nicht indexiert.

Gruß Jens