Verbindung mit Datenbank hergestellt, aber keine Nutzung möglich

verwendetes Datenbanksystem: MS SQL Server 2008 Express

Hallo,

Ich habe folgendes, komisches Problem:
Seit einiger Zeit Arbeite ich an einem Datenbank Frontend, was auf einem Windws XP Rechner bisher wunderbar gelaufen ist. Aufgrund von alter Rechner Kaputt habe ich halt einen neuen Rechner mit Win7 aufgesetzt. SQL Server wieder installiert, Pflichtservicepack aufgespielt, DB wieder eingerichtet, Lokalen Nutzer Rechte gegeben und die Daten wiederhergestellt,...

Das Problem fängt erst an, wenn ich nun mittels des Frontendes die Datenbank nutzen will. Die alte Connection Methode über Windows Authentifizierung funktioniert immernoch reibungslos, keine der Execute Funktionen wirft keine Exception, aber Sämtliche Abfrage liefern eine Leere Tabelle oder eine -1 zurück. An den Rechten kann es nicht liegen, denn dieses passiert selbst, wenn ich mich über den Connection string als "sa" samt entsprechenden Passwort anmelde. Wenngleich der Lokale nutzer auch alle rechte sowie zugriff hat. Über das Management Studio habe ich auch mit Windows Authentifizierung sämtliche rechte, die ich benötige. Die Verbindung wird mittels ADO.net hergestellt.

Der SQL Server läuft lokal auf dem Rechner, ist lokal erreichbar, die Zieldatenbank ist korrekt benannt und existent, Tabellen mit den Daten sind auch vorhanden. Früher lief auch das alles reibungslos. Die Suchfunktion und Google habe ich auch genutzt, bin nur irgendwie nicht auf ein ähnliches Problem dabei gestoßen. Und da -wie erwähnt- das alles vorher Funktionierte, wüsste ich auch nicht, welcher Code dabei hilfreich sein sollte, die Ursache zu finden.

Daher dann letztlich die Frage, ob ihr eine Idee habt, woran es sonst noch liegen könnte, dass ich mit dem Frontend keinen wirklichen zugriff bekomme.

Vielen dank im voraus,
Kelmoir

huhu,

ein paar Sachen schliesst Du bereits aus: mangelnde Rechte lösen eine Exception aus, Windows Anmeldung bzw. SQL-Server geht auch. Fehlende Rechte bei SP lösen auch ne Exception aus.

Ich finde jetzt nur 4 Erklärungen:

a) Es gibt eine zweite Instanz von SQL-Server mit den DB's und eine hat die Datenstruktur aber keine Daten. (oder tatsächlich ein ganz anderer Rechner/Server?) Im SSMS verbindest und testest du auf die andere DB mit Daten.

b) Es gibt eine Daten-Einschränkung auf den Benutzer (ja, man kann unter SQl-Server angeben welcher Benutzer welche Daten selectieren darf) - wenn das aber nicht explizit eingestellt wird, kommt es nicht vor.

c) Abfrage über SP's mit expliziter Authetifizierung (selst gebaut) welche dann nichts oder "-1" zurückgibt.

d) der DB- oder BI-Layer hält die Daten zurück und/oder filtert die aus.

Lösung: mal SQL-Profiler anwerfen und gucken was da an Anfragen wirklich reinkommt. wenn nicht kommt, dann ist es der falsche Server, wenn der Server Daten rausgibt ist es das Programm.

😃

Xynratron

PS: wo wird denn "-1" zurückgegeben? kein SQl-Server macht das freiwillig.

Hallo Xynratron,

ergebnis = m_SQL_query.ExecuteNonQuery();

Brachte beim versuch, ein externes Scipt, welches eine Tabelle mit 426 Zeilen enthielt, über das Frontend auszuführen die "-1" als Ergebnis. Das Script wurde selbstverständlich vorher eingelesen, und dem Objekt als command string übergeben. Funktionierte aber ebend nicht.

Das Management Studio war auch nicht in der Lage, dieses Script als ganzes auszuführen - Fehler wurde als Message Box geworfen, irgend etwas von wegen Starten des Debuggers wäre nicht möglich. Mittlerweile bin ich durch einen anderen Bekannten darauf gekommen, das Ganze in Teile zu zerlegen, und es ging. Komisch. Wenngleich es beim erneuten versucht nur die erwarteten Meldungen mit doppelten PK gibt, und deshalb die Datensätze nicht eingepflegt werden können. Und nicht der Echte Fehler mit der MessageBox - weswegen ich auch nicht mehr ganz genau weiss, was exakt drinnen stand.

Jedenfalls konnte ich dadurch auch diese letzte Tabelle wiederherstellen. Das Script funktioniert zwar so immer noch nicht über das Frontend, aber mittlerweile funktionieren die alten Abfragen wieder. Diese Tabelle enthielt essentielle Daten. Wie das später mal für Wiederherstellung bei unterschiedlichen Db-versionen genutzt wird, muss ich dann noch einmal gesondert betrachten...

Damit konnten die Essentiellen Teile des Problems gelöst werden, auch wenn es nicht auf deine Erklärungen zurückgeführt werden konnte.

Danke dennoch,
Kelmoir