MDD

Guten Morgen Mir sind 2 Sachen noch nicht klar. Du schreibst dass der Fehler passiert wenn du auf Durchsuchen klickst. "Welches Durchsuchen" , Pfad fürs Backup File, fürs Ziel Verzeichnis, ...? Welches Version von SSMS verwendest du? 3 verschiedene Sachen fallen mir ein die man probieren könnte. 1) SSMS im Administratormodus starten 2) Je nach dem welches "Verzeichnis durchsuchen" gemeint ist, auch die Datei an sich zu überprüfen 3) Die Wiederherstellung nicht über eine leere Datenbank starten, sondern über die Verzweigung "Datenbanken". 4) Das ganze mit TSQL zu machen - damit die DB jedenfalls wieder läuft Gruß MDD

Hallo Was ist denn das für eine ältere Version von der die Datenbank stammt? Gruß MDD

Hallo bezieht sich die Frage auf die Job History oder auf das Log vom Agent? Gruß MDD

Hallo ohne es vorher probiert zu haben würde wahrscheinlich folgendes funktionieren. Select Artikel, count(*) from ( select distinct artikel, Land from Tabelle) as x group by Artikel geht vielleicht noch eleganter Gruß MDD

Hallo Ich gehe davon aus dass du diesen Tag als Parameter an die Abfrage weiterreichst. Declare @tag as date @tag = '20190627' SELECT Timestamp, Kostenstelle FROM TUmsatz WHERE Timestamp  between @tag and dateadd (d,1,@tag) Richtigerweise muss ich dazu sagen dass jetzt auch Daten mit vom Zeitpunkt 28.6.2019 00:00:00.000 mit aufgeführt würden. Ansonsten musst du wirklich mit >= und < arbeiten. Gruß MDD

Hallo DELETE * FROM TabelleB where ID in (SELECT ID FROM TabelleA where bisdatum < CAST(GETDATE() as Date)) DELETE * FROM TabelleC where AusweisNr in (SELECT ID FROM TabelleA where bisdatum < CAST(GETDATE() as Date)) DELETE * FROM TabelleA where bisdatum < CAST(GETDATE() as Date) Damit sollte zuerst aus den "Untertabellen" die Datensätze rausgeschmissen werden die älter sind als der aktuelle Tag sind und zuletzt die Tabelle A selbst bereinigen werden. Bei Bedarf kann man das Ergebnis der Unterabfrage von Tabelle A auch temporär zwischenspeichern und damit nur 1x abfragen. Zuerst Daten sichern dann probieren ;) Gruß MDD --- Klammer entfernt

Guten Morgen kann es sein dass die Checkbox "User must change the password at next login" zwar ausgegraut aber ausgewählt ist? Das würde eine Pattsituation erklären. Mit diesem Statement solltest du es es lösen können: ALTER LOGIN [LoginName] WITH PASSWORD = 'newpassword', CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF Gruss MDD

Zum Programm gehören mehrere Datenbanken mit unterschiedlich vielen Tabellen (zwischen 10 und 150 Tabellen). Zugriff erfolgt zentral über die Client/Server Applikation. Daher haben wir nur einige Dutzend Verbindungen. Abfragen mit mehreren Joins sind viele vorhanden. Sie deswegen als komplex zu bezeichnen liegt wohl mehr im Auge des Betrachters und ist schwer objektiv zu beurteilen. Ich würde den syntaktischen Umfang als beschränkt einstufen. Gruß MDD

Hallo Mit den "richtigen" Abfragen kann man die DB immer an die Grenzen treiben. Wir arbeiten auch recht intensiv mit der Express Edition und Datenbanken mit bis zu mehreren GB. Wenn wir da wirklich auf Probleme stoßen, dann meist wegen Designfehlern bei der DB oder bei den Abfragen.

Guten Morgen, kann es sein dass es mit den Benutzerberechtigungen zusammenhängt. Kannst du mit den Benutzerrechten des SAP Clients auf die Datenbank zugreifen und schreiben? Möglicherweise hast du nur Leserechte. Gruß MDD

Hallo imho wird der Platz ganz normal freigegeben und für andere Inhalte verwendet. Genauso wie jeder andere Platz im mdf File.

Hallo, Der User mit dem du dich zum SQL verbindest benötigt die entsprechenden Rechte auf der Datenbank. Sind die Berechtigungen richtig eingestellt? Gruß MDD

Hallo kann es sein dass du im SQL Server Configuration Manager TCP/IP nicht aktiviert hast? Das ist standardmäßig deaktiviert. Gruß MDD

Hallo Wie schaut dein Insert-Statement aus mit dem der Trigger ausgelöst wird. Kann es sein dass du gar nicht alle Spalten befüllst obwohl das vielleicht nötig wäre und daher der Trigger auf einen Fehler läuft? Gruß MDD

Vielleicht hilft da der sogenannte Kompatibiltätsgrad (100 für SQL2008) in der Datenbank. Damit sollte auch "veraltete" Aufrufe noch funktionieren.

Hallo Nein das geht nicht

Hallo sp_who2 liefert noch ein wenig mehr Infos als sp_who. Auch die Tabelle master.dbo.sysprocesses kann auch hilfreich sein. Beide liefern Daten zu bestehenden Verbindungen. Infos über vergangene Zugriffe wird schwieriger. Auch wie man direkt die IP einer Verbindung beim 2000er rauskriegt ist mir nicht bekannt. Ich hoffe es reicht dir der Hostname. Ansonsten hast ja die MacAdresse (master.dbo.sysprocesses net_addresss), genauer gehts dann wirklich nicht :D Beim Änderungsdatum einer Protokolldatei bitte bedenken dass hier auch Veränderungen aufgrund von irgendwelchen Wartungsaufgaben drinnen sein könnten. Gruß MDD

Hallo. Die Fehlermeldung an sich hatte ich noch nie. Nach dem beschriebenen Ablauf nach zu urteilen hast du die Datenbankfiles einfach zurück kopiert. Ich könnte mir jetzt folgende Ursachen vorstellen. a) Die Filenamen oder der Pfad der alten Datenbank passen nicht mit den neuen zusammen. b) Das Programm hatte nach der Grundinstallation noch Updates welche die interne Datenbank Version verändert haben, wenn du jetzt nur die Grundinstallation gemacht hast passt die Datenbank Version nicht mehr mit der Programmversion zusammen. Hast / Kannst du diese Sachen prüfen?

Hallo ssd_rider die Information stammt glaub ich aus der DMV für die Performance Counter. Die gibt aber nur eine Gesamtzahl wieder. SELECT * FROM sys.dm_os_performance_counters Ob sich auch was aus den Untiefen der Systemtabellen raussaugen lässt kann ich dir leider nicht sagen. Gruß MDD

Morgen, was mich stutzig macht ist folgende Aussage: 10 GB finde ich für eine DB nicht groß. Das man durch Auswertungen das System dadurch fast zum stehen bringt verwundert mich ein wenig. (Aber es fehlt noch einiges an Informationen über die Umgebung). Durch deine Lösungswege 1 und 2 wirst du meines Erachtens in erster Linie Locking Problemen aus dem Weg gehen. Wenn die "neue" DB dazu noch auf einem anderen Rechner liegt wirst du möglicherweise auch Ressourcen-Engpässe verringern. Ohne eine Analyse wo das Problem liegt wirst du aber vermutlich das falsche Problem lösen. Und das Thema Indexe ist, wie Sanches sagt, hier sicher ein wichtiger Ansatz. Genauso wie das Thema Wartung der Indexe; zu gern passiert es, dass diese aus irgendeinem Grund die Wartung auf einmal nicht mehr passiert und dann die besten Indexe nicht mehr verwendet werden können. Gruß MDD

Weiterer Ansatz ab MSSQL 2008 zumindest innerhalb des Management Studios INSERT INTO Tabelle1 ( Spalte2, Kostenstelle ) OUTPUT inserted.* SELECT Max([spalte2])+1 AS SpalteX, Tabelle1.Kostenstelle FROM Tabelle1 WHERE Tabelle1.Kostenstelle='30300'; Hängt aber ganz ab womit du die Daten verarbeiten willst/musst. Schönes WE MDD

Tach, Du hast absolut recht. Hab ich übersehen. Wer lesen kann ist klar im Vorteil. :suspect: Gruß MDD

Moin, Wenn ich die Aufgabenstellung richtig verstanden habe, gibt es in der Tabelle mehrere Einträge pro Kostenstelle, ansonsten würde es keinen Sinn machen den höchsten Wert pro Kostenstelle zu suchen. Das heißt man müsste das "Wähle aus"-Statement durch ein "Einfüge"-Statement ersetzen. EDIT siehe Post #4: Stichworte für die Suche nach dem höchsten Wort: GROUP BY sowie MAX() Gruß MDD

Ich hatte weniger Probleme wenn ich den Kopiervorgang vom Zielserver aus gestartet habe.

Leider ist der Kompatibilitätsgrad nicht ausschlaggebend. Es wäre für mich oft schön und hilfreich gewesen wenn der ausreichend wäre. :nene: https://technet.microsoft.com/en-us/library/ms190436(v=sql.110).aspx Man kann Backups nur auf der selben oder höheren Versionen wiederherstellen. Sorry Dafür íst entweder explizit eines der Rechte CREATE DATABASE, CREATE ANY DATABASE oder ALTER ANY DATABASE notwendig. Oder wenn ein Benutzer Mitglied der Standard Rollen sysadmin bzw dbcreator ist. Bei einer bestehenden Datenbank funktioniert es auch mit der Gruppe db_owner.