t-sql

Richtig machen heißt nicht "reine Lehre". Wenn die Aufgabe darin bestand SQL Server 2022 auf einem bestehenden Server mit SQL Server 2012 zu installieren dann fragt man vorher ob, man den deinstallieren kann. Offensichtlich wusste ja der Dienstleister nicht was er tut. Die Aussage "es könnte durch entfernen eine alten Version spezielle Runtimes der aktuellen Version entfernt werden." geh ich mit wenn man die alte Version drauf lässt. Aber nicht wenn der alte sauber deinstalliert wurde. Was bei dem Vorgehen passieren kann? Ein inkonstentes System, Im Config Manager werden auch die anderen Dienste angezeigt, disabled aber da. Dann kommt die Frage "Warum sind die deaktiviert?". Jemand anders fährt die deaktivierten Dienste hoch usw., usw.. Eine Überwachung prüft den SQL Server Dienst. Der neue hat den gleichen Namen wie der alte. Welcher ist nun der korrekte? Parallele Neuinstallation von SQL Server ist NIE notwendig. Außerdem hab ich noch die Lizenzfrage vergessen. Muss man für einen deaktivierten SQL Server ebenfalls Lizenzkosten zahlen? Sprich zwei SQL Server Installationen, zwei mal Lizenzkosten. Windows Server Inplace Upgrade würde ich auch nicht machen. SQL Server Inplace, kein Problem. Was issn IU?

Hallo @Dutch_OnE, 1. was genau haben die gemacht? den SQL Server 2022 zusätzlich installiert oder ein Inplace Upgrade des SQL Server 2012 gemacht? 2. Falls die SQL Server 2022 neben 2012er installiert haben und danach den 2012 deaktiviert haben war das Vorgehen völlig falsch und mehr als amateurhaft. Schließlich deinstalliert man VOR der anderen Installation den 2012er und dann passiert auch nix. 3. Such dir ne Firma die sich auch wirklich mit SQL Server auskennt. Dein aktueller Dienstleister kennt sich damit anscheinend nicht aus. Was fürn "Zusatzaufwand" wäre es denn es richtig zu machen? Sprich VOR der Installation des SQL Server 2022 den alten runterzuschmeißen. Das ist der korrekte Weg. Ich hätte meinen Mitarbeitern gesagt: 1. Macht vorher ein Backup der Datenbanken, 2. deinstalliert dein 2012er, 3. installiert den 2022er. Dann sag ihnen sie sollen es nochmal machen und dann auch richtig.

Ihr nehmt SSIS. Also isses net zeitkritisch. Ich würd da mit Logshipping anfangen. BTW. der SQL Server Replikation is die Datenbankstruktur völlig wurscht.

Nee, du meinst: Gibts umsonst aber net kostenlos. So wird n Schuh draus.

Alles klar. Dann installier mal die aktuellste OBDC Treiber Version für den SQL Server, aktuell 181.2.1 Vermutlich nur ein Schreibfehler von Dir. Seis drum. Die Servicepacks gibts umsonst

Dann ist die erste Maßnahme die Kiste mal auf SP3 zu heben

Das ist leider für das Szenario nicht geeignet. Schließlich ist Always On eine HA Lösung. Außerdem meinst Du sicherlich Always On Availability Groups und nicht Always On Failover Cluster. Das Szenario funktioniert nur mit Copy Only Backups. Oder es wird zeitgesteuert aus der Backuplösung ein Restore gemacht.

Die Pivot Funktion ist da genau das Richtige.

Ich würde da mit ltrim() und rtrim() arbeiten.

Wir bekommen diese Meldungen immer wenn Passwörter der zugehörigen Domain User abgelaufen sind. Soll heißen: Passwort wird geändert, User is noch irgendwo mit dem alten Passwort angemeldet. Im Endeffekt isses erstmal nix dramatisches.

Nö, wumpe isses net. Support hat nix mit Netz tun oder nicht. Software betreibt man, gerade in einer Produktivumgebung (wovon ich mal ausgehe), IMMER mit Herstellersupport. Alles andere ist fahrlässig. Tritt ein Fehler auf, dazu solltest du dir mal durch lesen was alles in SP3 gefixt wurde, kriegste halt keine Lösung, fertig. Heißt im besten Fall stehen halt deine embedded Maschinen. Und ich hoffe, dein Kunde will veraltete Software einsetzen und ihr habt ihn nicht falsch beraten.

Deinem Kunden is hoffentlich klar, das es in knapp einem Monat keinerlei Support mehr für SQL Server 2016 SP2 geben wird

Das war mir auch klar. Nur deine Frage ist falsch gestellt. PS mit T-SQL zu vergleichen, was deine Frage ja impliziert, ist wie Äpfel mit Birnen. @LTTG | @LTTG2 probier mal den Port 25 anstatt 587

Doch gibt es. Das eine is Powershell und das andere T-SQL ;-). T-SQL selbst verschickt keine Mails. Das wird das Database Mail Subsystem übergeben.

Ich würde jetzt mal mit Wireshark mit sniffen wenn Du aus dem SQL Server verschickst. BTW. Du benutzt hoffentlich beim testen das korrekte Mail Profil? Gerade noch was interessantes gefunden: Enable TLS 1.2 for SQL Server 2016 database mail - Database Administrators Stack Exchange und dort die Antwort vom MS Support

ok. Kommst Du überhaupt von deinem SQL Server Server zu smtp.office365.com Port 587 hin oder wird da was von einer Firewall geblockt? Außerdem hab ich noch den Artikel How to configure SQL Database mail so send emails using Office 365 (Exchange Online): A walkthrough | Microsoft Docs gefunden.

Was hier erstmal fehlt sind die Ausgaben aus dem Errorlog. Was steht denn da drin? Was geben denn die passen Systemviews zu Database Mail aus? Siehe hier Database Mail Views (Transact-SQL) - SQL Server | Microsoft Docs

Dein Fehler ist sehr einfach zu erklären. Im where Teil ist der Alias aus dem Select Teil noch nicht bekannt. Die Ausführungsreihenfolge ist nämlich: FROM – inputs are evaluated first JOIN WHERE GROUP BY HAVING SELECT DISTINCT ORDER BY TOP – this is the last step aus T-SQL processing order

Was in dem Fall das gleiche ist.

Ähm, auf Server installiert man kein SSMS. Das gehört auf einen Client.

Hallo Sugar432, leider sind deine Annahmen zu Instanzen falsch. Instanzen kennen sich nicht. Auch nicht wenn sie auf dem gleichen Server sind. Instanzen haben unterschiedliche Namen. Die einzige Möglichkeit besteht über Linked Server zu arbeiten oder über openrowset.