Fehlermeldung beim Aktualisieren einer SQL Server 2000-Tabelle äber einen Verbindungsserver

Beschreibung

In einem Szenario hatten wir 2 Microsoft SQL Server 2000 (Server A und B). der eine hat den anderen als Verbindungsserver („Linked server“) eingebunden.

Wenn nun von einer Datenbank auf Server B eine SELECT-SQL-Abfrage auf eine Tabelle in einer Datenbank auf Server A ausgeführt wurde, so hat dies korrekt funktioniert.

Wurde jedoch eine UPDATE-SQL-Abfrage ausgeführt, so kam eine Fehlermeldung.

Die auszuführende Abfrage war in etwa:

UPDATE [MyTable]
SET [Credit Limit Block]=2
WHERE [No.]=’000102628521′

(also eine Abfrage auf Spaltennamen mit Leerzeichen).

Als Fehlermeldung erschien dann:

Server: Nachr.-Nr. 8180, Schweregrad 16, Status 1, Zeile 1
Statement(s) could not be prepared.
Server: Nachr.-Nr. 170, Schweregrad 15, Status 1, Zeile 1
Line 1: Incorrect syntax near ‚Limit‘.

Ursache

Scheinbar hat der SQL Server 2000 bei bestimmten Konfigurationsparametern Probleme bei UPDATE-Abfragen über einen Verbindungsserver, wenn Feldern mit Leerzeichen beteiligt sind.

Dies waren die ursprünglichen Einstellungen des Verbindungsservers:

Verbindungsserver-Einstellungen die in meinem Fall die UPDATE-Anweisung fehlschlagen ließen
Fehlgeschlagen

Damit kam die Fehlermeldung.

Bei Google habe ich unter anderem folgende Zitate gefunden:

…If I was to remove the space from (my colum name) [f 1] and use [f1] it would work fine…

Und

I’ve seen this before, and I’m quite sure that I have reported it to
Microsoft. However, it does not seem have been fixed in SQL 2000. The
error is that when the query is submitted to the remote server, the
brackets are missing.

Lösung

Da ich ein anderes, fast gleichwertiges, System hatte, auf dem die UPDATE-Abfrage korrekt funktionierte, habe ich die Einstellungen des Verbindungsservers verglichen und die Option gefunden, die in meinem Fall die Lösung war:

Verbindungsserver-Einstellungen die in meinem Fall die UPDATE-Anweisung erfolgreich ausführen ließen
Erfolgreich

Ich habe also schlicht die Option „Remotesortierung verwenden“ deaktiviert. Danach funktionierte meine Abfrage.

Ob das in jedem Fall eine praktikable Lösung ist, weiß ich leider nicht, jedoch in meinem Fall war dies ausreichend.

Fehlermeldung CS0013 beim Kompilieren einer ASP.NET 1.1-Anwendung mit Microsoft Visual Studio .NET 2003

Beschreibung

Beim Kompilieren einer ASP.NET 1.1-Anwendung mit Microsoft Visual Studio .NET 2003 auf einem Windows 2000 Server via Terminal Services („Remote Desktop“, RDP) trat folgende Fehlermeldung auf:

CS0013: Unerwarteter Fehler beim Schreiben der Metadaten in die Datei ‚C:\…\obj\Release\MyDll.dll‘ — ‚Unbekannter Fehler‘.

In Englisch sollte das in etwa so lauten:

CS0013: Unexpected error writing metadata to file ‚C:\…\obj\Release\MyDll.dll‘ — ‚Unknown error‘.

Die Fehlermeldung trat bei einem Projekt auf, das bereits über ein Jahr erfolgreich kompilierte. Nach einer kleinen Codeänderung kam auf einmal diese Fehlermeldung.

Ursache

Die erwähnte „kleine Codeänderung“ war, daß ich eine Klasse erstellt hatte, die von einer anderen Klasse abgeleitet hat, welche in einer dritten Klasse als Unterklasse enthalten war.

Also so was wie das hier:

public class A
{
    ...
    
    public class B
    {
        ....
    }

    ...
}

...

public class C : A.B
{
    ...
}

Scheinbar „verhaspelt“ sich der C#-Compiler da irgendwo. In anderen Fällen hat das selbe Prinzip auch schon oft funktioniert. Nur in diesem Fall hier aus irgendeinem Grund nicht.

Lösung

Nachdem ich die Klasse B „global“ gemacht hatte, kompilierte alles wieder:

public class A
{
    ... 
}

...

public class B
{
    ....
}

...

public class C : B
{
    ...
}

Fehlermeldung „Fehler bei sqlmaint.exe“ bei einem geplanten Auftrag in SQL Server

Fehlerbeschreibung

Es kommt eine Meldung „Fehler bei sqlmaint.exe. [SQLSTATE 42000] (Fehler 22029). Fehler bei Schritt“ und der Auftrag ist mit einem roten X als fehlgeschlagen markiert.

Ursache

Der Aufruf der Anwendung „sqlmaint.exe“ schlug fehl.

Lösung

Zunächst den Auftrag anschauen und das T-SQL-Skripts des Auftrags analysieren. Dies kann z.B. wie folgt aussehen:

EXECUTE
    master.dbo.xp_sqlmaint
    N"-PlanID 99F45116-2803-46BB-A95D-058C5D8E72EC
    -WriteHistory
    -VrfyBackup
    -BkUpOnlyIfClean
    -CkDBRepair
    -BkUpMedia DISK
    -BkUpDB "c:mybackfolder"
    -DelBkUps 4DAYS
    -BkExt "BAK""

Der Aufruf „xp_sqlmaint“ ist eine Erweiterte Gespeicherte Prozedur die schlicht ein Wrapper für die Anwendung „sqlmaint.exe“ ist.

Wenn nun „sqlmaint.exe“ direkt von der Befehlszeile aus aufgerufen wird mit den Parametern die auch an „xp_sqlmaint“ übergeben wird, liefert „sqlmaint.exe“ eine sehr detaillierte Fehlermeldung warum der Aufruf tatsächlich fehlschlug.

Mit dieser Fehlermeldung dann die tatsächliche Ursache beseitigen.

Noch einfacher ist es, die Ausgabe von „sqlmaint.exe“ wenn es durch „xp_sqlmaint“ aufgerufen wird sich direkt ausgeben zu lassen. Dazu:

Eigenschaften des T-SQL-Skripts des Auftrags anzeigen.
Registerkarte „Erweitert“
Im Feld Ausgabedatei einen Datei angeben, möglichst als UNC-Pfad, z. B. „\\myserver\myfolder\sqlmaint-output.txt“. Diese Ausgabe dann analysieren.

Tipps

„sqlmaint.exe“ ist normalerweise im Ordner „C:\Programme\Microsoft SQL Server\MSSQL\Binn“ gespeichert. (bzw. „C:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\Binn“ für SQL Server 2005)
Ein Fehler war „Error 21268: [SQL-DMO]Row or column specified is outside the range of the specified query result set„. Ein Autor schlug vor, die Begrenzung der Zeilenanzahl für Protokolle aufzuheben, ein anderer „dbcc checkdb“ auf der Datenbank auszuführen (im SQL Query Analyzer). Es wurden dann auch tatsächlich Fehler in der „msdb“ Datenbank gefunden. Um diese zu beseitigen:
1. Den SQL-Server Dienst anhalten
2. Den SQL-Server manuell starten „C:\Programme\Microsoft SQL Server\MSSQL\Binn>sqlservr.exe -m“
3. „ISQL.exe“ starten
  „C:\Programme\Microsoft SQL Server\MSSQL\Binn>isql -U sa“ und den Reparieren-Befehl ausführen, z.B.:
  1> alter database msdb set SINGLE_USER
  2> DBCC CHECKDB („msdb“, REPAIR_ALLOW_DATA_LOSS)
  3> alter database msdb set MULTI_USER
  4> GO
Für den SQL Server 2005 lauten die entsprechenden Befehle/Ordner:
1. Den SQL-Server Dienst anhalten
2. Den SQL-Server manuell starten „C:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\Binn>sqlservr.exe -m„
3. „OSQL.exe“ starten
  „C:\Programme\Microsoft SQL Server\90\Tools\Binn>osql -U sa“ und den Reparieren-Befehl ausführen, z.B.:
  1> alter database msdb set SINGLE_USER
  2> DBCC CHECKDB („msdb“, REPAIR_ALLOW_DATA_LOSS)
  3> alter database msdb set MULTI_USER
  4> GO

(Stichwörter für Suchmaschinen: )