BlogEngine Update 2.5.0.X auf 2.5.011 – Datenbank Update notwendig

Heute Morgen wollte ich „schnell“ meinen BlogEngine betriebenen Blog auf http://blog.schelian.com mit der neuen Version 2.5.0.11 aktualisieren.

Diese Version ist die erste, welche eine komplette Gallery Integration (Installation, Update und löschen) von Paketen enthält.

Da ich einige persönliche Änderungen der BlogEngine vorgenommen habe, musste ich zuerst eine Verschmelzung (Merge) der Original Version 2.5.0.11 mit meiner lokale geänderten Version, die aber schon auf dem Code Version 2.5.0.10 basiert, vornehmen.

Der Merge konnte ohne manuelle Nacharbeiten einfach so durchgeführt werden.

Nach der Aktualisierung meins lokalen Quellcodes habe ich in Visual Studio 2010 einen kurzen Testlauf durchgeführt (mit XML Provider) und konnte keinen Fehler feststellen.

Nun habe ich mein NANT Skript aufgerufen, was mir aus der lokalen Version ein Package zur Aktualisierung meines Servers erstellt.

Das dabei erstellt ZIP File mit der Version 2.5.0.11 (in meiner angepassten Version) dann auf den Server hochgeladen und im Root Verzeichnis der BlogEngine entpackt (natürlich nicht ohne vorher eine Datensicherung durchgeführt zu haben).

Nun den Blog aufgerufen und…..

…. auf den ersten Blick war alles in Ordnung, nur auf den zweiten Blick leider nicht.

Beim Aufruf der Seite Plugins gab es eine Fehlermeldung die sich in weitestem Sinne um folgenden Aufruf gedreht hat.

BlogEngine.Core.Packaging.PackageRepository.GetPackage

Eine kurze Recherche hat das gezeigt, dass das Problem dadurch entsteht, dass diese Methode versucht auf eine Tabelle im SQL Server zuzugreifen, die es „noch“ gar nicht gibt.

Da auf der Codeplex Seite keine Hinweis auf ein erweitertes Datenbankschema zu finden war, hatte ich auch nicht nach einem Skript zur Aktualisierung der Datenbank gesucht.

Es gibt aber tatsächlich ein Script, allerdings mit dem merkwürdigen Zukunftsweisenden Namen „MSSQLUpgradeFrom2.5to2.6„, also einer Aktualisierung die erst beim Update der BE von 2.5 auf 2.6 notwendig sein soll.

Aber gut, es ist nun mal so, dass folgendes Script schon bei einem Update einer Version 2.5.0.X auf 2.5.0.11 notwendig ist:

SET CONCAT_NULL_YIELDS_NULL, ANSI_NULLS, ANSI_PADDING, QUOTED_IDENTIFIER, ANSI_WARNINGS, ARITHABORT ON
SET NUMERIC_ROUNDABORT, IMPLICIT_TRANSACTIONS, XACT_ABORT OFF
GO

--
-- Create table "dbo.be_Packages"
--
CREATE TABLE dbo.be_Packages (
  [PackageId] nvarchar(128) NOT NULL,
  [Version] nvarchar(128) NOT NULL
)
GO

--
-- Create table "dbo.be_PackageFiles"
--
CREATE TABLE dbo.be_PackageFiles (
  [PackageId] nvarchar(128) NOT NULL,
  [FileOrder] int NOT NULL,
  [FilePath] nvarchar(255) NOT NULL,
  [IsDirectory] bit NOT NULL
)
GO

Nachdem ich diese Skript auf der Datenbank ausgeführt habe, war der Fehler behoben und das Update auf Version 2.5.0.11 erfolgreich abegschlossen.

SQL Server – Nach Neuinstallation SQL Server Express auf Dev Rechner Fehler mit DateTime Formaten

Ich will hier kein riesen Fass zum Thema SQL DateTime Formate aufmachen, dazu gibt es schon ganz viele Fässer im Internet, die das ganz ausführlich beschreiben.

In erster Linie geht es mir in diesem Artikel darum, mir selbst eine Nachricht zu hinterlassen, was ich beim nächsten mal machen muss, wenn ich ein solches Problem nochmal habe.

Eventuell hilft der Artikel auch mal jemand anderem, der das gleiche Problem hat, wie das, welches ich nun kurz beschreibe.

Hier nun das Problem:
Nach der Einrichtung eines neuen Entwickler Rechners, natürlich mit ein wenig aktuelleren Programmversionen als es auf dem bisherigen Rechern der Fall war, bekomme ich beim Versuch eine Windows Forms Anwendung[*1] aus Visual Studio heraus zu Debuggen Fehlermeldungen, wenn ich auf die lokale Datenbank die ich auf einem SQL Server Express 64 BIT, auf dem Rechner installiert habe, zugreifen möchte.

Das Programm läuft jedoch einwandfrei wenn ich Remote auf einen anderen SQL Server zugreife.

Da ich die lokale Datenbank aus einem aktuellen Backup des Servers erstellt habe auf dem es per Remote Zugriff keine Problem gibt, schließe ich schon mal aus das meine Datenbank selbst das Problem ist.

Die Fehlermeldung lautet wie folgt:

{„Bei der Konvertierung eines varchar-Datentyps in einen smalldatetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.“}

Probleme mit der Konvertierung von DateTime Werten, deutet auf ein Problem mit falschen Formaten hin. Die Standard Formate sind abhängig von der verwendeten Sprache.

Auf dem Rechner habe ich entgegen der bisherigen Installationen eine englische SQL Server Express Version installiert und nicht wie sonst einen deutsche Version.

Sowohl auf dem Produktionsserver des Kunden als auch auf meinem „echten“ Server ist aber der SQL Server als Deutsche Version installiert.

Soll das mein Problem sein? (Und es soll sich heraus stellen, dass mein Problem wenigstens damit zusammenhängt)

Mit dem Befehl

SELECT @@LANGUAGE

kann man die aktuellen Spracheinstellungen der aktuellen Verbindung abfragen.

Die Abfrage auf meinem lokalen SQL Express Server ergibt als Antwort English.

Eine Abfrage auf den „echten“ SQL Servern ergibt jeweils Deutsch.

Bingo, da liegt das Problem. Doch wie kann ich das ändern, bzw. was ich muss ich da überhaupt ändern.

Ich muss die Standard Sprache (Default Language) des SQL Login (Benutzer) ändern.

Das kann am einfachsten über die Login Eigenschaften mit dem SQL Server Management Studio machen.

Nun möchte ich aber vermeiden, dass beim nächsten Benutzer den ich anlege wieder die „für mich“ falsche Standardsprache des Benutzers hinterlegt wird.

Die Standardsprache kann man ebenfalls mit dem SQL Server Management Studio ansehen und auch ändern.

Hierzu öffnet man die Server Eigenschaften indem man im SQL Server Management Studio im Object Explorer auf dem Knotenpunkt des Server mit der rechen Maus das Kontextmenü öffnet und dort das Eigenschaften (Property) Fenster öffnet.

Und dort stellen wir die Default Language von English auf German um. Und schon wird beim nächsten Benutzer den man anlegt die „richtige“ Standardsprache für den Benutzer hinterlegt.

Natürlich kann man auch diese Einstellungen per SQL Befehle ausführen, aber wie ich bereits am Anfang sagte, ich möchte hier kein Riesen Fass öffnen, und es gibt ganz viele die sich mit dem SQL Server besser auskennen als ich.

Eventuell ist ja ein Leser des Berichtes so SQL fit und kann die SQL Befehle oder einen direkten Link zu den Befehlen als Kommentar hinterlassen.


[*1] ja die gibt es noch und diese von der ich hier sprechen ist auch schon einige Jahre alt, bzw, wird seit Jahren immer weiter entwickelt

SQL Server Management Studio – Select Top X und Edit Top X Beschränkung

Im Microsoft SQL Server Management Studio (SQL Server 2008) werden im Kontextmenü zu Tables (Tabellen) und Views (Sichten) die beiden nachfolgenden Funktionen angeboten:

  • Select Top 1000 rows (Oberste 1000 Zeilen auswählen)
  • Edit Top 200 rows (Oberste 200 Zeilen bearbeiten)

Über den Sinn oder Unsinn warum man in einer View die Möglichkeit der Bearbeitung angeboten bekommt, möchte ich an dieser Stelle nicht weiter sprechen.

Nun ist es aber so, dass mich, diese Einschränkung stört!

Wenn ich eine Tabelle oder Sicht angezeigt bekomme,  möchte ich diese mit allen Datensätzen und nicht nur mit den ersten 1000 angezeigt bekommen.

Das gleich gilt übrigens auch für die Bearbeitung.

Nun gibt es, „Microsoft sei Dank“ die Möglichkeit, diese Einschränkung in den Optionen zum SQL Server Management Studio einstellen zu können.

Diese Option finden wir unter:

Tools -> Options -> SQL Server Object Explorer

oder für die eingefleischten Deutsch Programm Anwender:

Extras -> Optionen -> Objekt-Explorer von SQL Server

Dort finden wir  unter Table and View Options (Tabellen- und Sichtoptionen)

Die beiden Einträge:

Englische Version Deutsche Version

Nun kann man diese Werte beliebig ändern.

Oder wenn man wie ich keine Einschränkung haben möchte (alle Datensätze), kann man den Wert 0 eintragen.

Dann sieht das Kontextmenü wir folgt aus:

SQL View – Manchmal darf’s nicht null sein !

In einer SQL View soll eine Spalte als (int, NULL) ausgegeben werden, die in der zugrundeliegenden Tabelle als Spaltentyp (int, Not NULL) definiert ist.

Hintergrund dieser Forderung ist, das die View als Datasource für ein recht aufwendig zu formatierendes DataGridView dient und bei der Formatierung dieser Spalte nicht als (not null) definiert sein darf.

Mit einem einfachen Cast direkt in der View ist diese Anforderung sehr einfach umzusetzen. (siehe nachfolgenden Code Abschnitt)

SELECT CAST(dbo.MyTable.ID AS int) AS MyID, .....

FROM MyTable

SQL Transaktionsprotokoll verkleinern (sichern) – SQL 2005 – SQL 2008

Bereits vor 6 Jahren (wie die Zeit vergeht) hatte ich in einem Artikel „SQL 2000 Transaktionsprotokoll verkleinern“ beschrieben wie man ein zu groß gewordenes Transaktionsprotokoll verkleinern kann.

Da die neuere Version SQL 2008 nicht mehr über die Option WITH TRUNCATE_ONLY verfügt, funktioniert die beschrieben Methode nicht mehr.

Nachfolgend möchte ich daher eine alternative Method vorstellen, welche den gleichen  gewünschten Effekt hat.

Das verkleinern des Transaktionsprotokolls.

Damit die Verkleinerung des Transaktionprotokolls nicht zu problemen bei einer eventuellen Rücksicherung führt, würde ich vor dem verkleinern unbedingt eine Sicherung der Datenbank und des Transaktionsprotokolls durchführen. Denn nur die Sicherung des Transaktionsprotokolls ermöglicht auch das spätere verkleinern.

Hier also nun der Transakt SQL Code zur Speicherung der DB und des Logs mit anschließendem Verkleiner der Transaktionsprotokoll Datei.

USE pubs
BACKUP DATABASE pubs TO DISK='C:\SqlDataBackup\pubs.bak' WITH INIT
BACKUP LOG pubs_log TO DISK='C:\SqlDataBackup\pubs_log.bak' WITH INIT
DBCC SHRINKFILE(pubs_Log, 10)
GO

Am besten kann man das in einer Batch Datei (Kommando Stapeldatei) einbauen und z. B. regelmäßig als Tast auf dem Rechner laufen lassen.
Wer das regelmäßig ausführen möchte kann das auch in eine Batch Datei packen und von der Kommandozeile ausführen. Was übrigens auch dann als Task ausgeführt werden kann.

@ECHO OFF
set SQL_UTIL_HOME="%ProgramFiles%\Microsoft SQL Server\100\Tools\Binn\osql"
rem Tragen Sie in der nachfolgenden Zeile den Namen des SQL Server ein z.B. (localhost)
set SQL_SERVERNAME=localhost
rem Tragen Sie in der nachfolgenden Zeile den Namen der zu sichernden Datenbank ein
set SQL_DBNAME=pubs
set SQL_LOGNAME=pubs_log
rem Tragen sie den Namen inkl. Pfad der Backup Datei ein
set SQL_BACKUP_FILE='C:\SqlBackup\pubs.BAK'
set SQL_LOG_FILE='C:\SqlBackup\pubs_log.BAK'
@ECHO ON
@ECHO Datenbank sichern
%SQL_UTIL_HOME% -S%SQL_SERVERNAME% -E -n -Q "BACKUP DATABASE %SQL_DBNAME% TO DISK = %SQL_BACKUP_FILE% WITH INIT;"
@ECHO Protokolldatei sichern
%SQL_UTIL_HOME% -S%SQL_SERVERNAME% -E -n -Q "BACKUP LOG %SQL_DBNAME% TO DISK = %SQL_LOG_FILE% WITH INIT;"
@ECHO Protokolldatei verkleinern
%SQL_UTIL_HOME% -S%SQL_SERVERNAME% -E -n -d%SQL_DBNAME%  -Q "DBCC SHRINKFILE(%SQL_LOGNAME%, 10)"

Wenn man nun noch ein Backup Programm wie Cobian Backup verwendet um die erzeugten Datenbank Backup Dateien auf einen FTP Server zu sichern, hat man eine kostenlose Lösung zur Sicherung der SQL Datenbank.

Ich denke, ich werde bald man in einem neuen Beitrag beschreiben, wie man Dedizierte WEB Server, die man bei einem Hoster stehen hat, mit Hilfe von Batch Dateien und Cobian Backup WEB Seiten inkl. Datenbanken ganz einfach und kostenlos sichern kann.

MS SQL – Views ermitteln in welchen ein bestimmtes Feld verwendet wird

In einem recht umfangreichen Projekt (C# Windows Forms Anwendung) welches als Datenbank eine MS SQL Datenbank verwendet, musste ich Erweiterungen der Datenbank (zusätzliche Felder) vornehmen.

Da ich diese neuen Felder auch in allen vorhandenen Abfragen ergänzen musste, in welchen ein anders bereits vorhandenes Feld (wir nennen es einfach mal “EinfahrtLKW”) der gleichen Tabelle ausgegeben wird, habe ich nach einer Lösung gesucht um mir alle Abfragen (Views) anzeigen zu lassen, in dem das Feld EinfahrtLKW Verwendung findet.

Um dies zu realisieren habe ich folgende Systemsicht verwendet:

INFORMATION_SCHEMA.VIEW_COLUMN_USAGE

Meine Abfrage sieht dann so aus:

select * from INFORMATION_SCHEMA.VIEW_COLUMN_USAGE where COLUMN_NAME = 'EinfahrtLKW'

Und das Ergebnis sieht dann so aus:

 image

Mit dieser Information habe ich nun die Name der Views, die ich anpassen muss.

DotNetNuke Module – DMX von Bring2Mind Problem mit DNN 5.X – SQL Hack

Bei dem hier beschrieben Problem und deren BUGFIX handelt es sich um die DMX Version 3.5.X und dem Update eines DNN 4.9.X Portals auf DNN 5.X.

Sicherlich die einfachste Methode ist einfach ein Update des DMX Moduls zu erwerben und dieses Update zu verwenden.

Wer das aber nicht möchte und mit dem Funktionsumfang der 3.5.X Version zufrieden ist, kann mithilfe des hier einfach beschriebenen SQL Patches die Version 3.5.X unter DNN 5.3.X (und vermutlich auch höher) zum laufen bekommen.

ACHTUNG auch hier gilt:

Vor der Manipulation unbedingt eines Sicherung (in diesem Fall genügt die Sicherung der Datenbank) vornehmen.

Hier nun die Vorgehensweise, nachdem man vermutlich erst nachdem man das DNN Portal von 4.X auf 5.X aktualisiert hat, feststellt, dass das DMX Modul nicht mehr funktioniert.

Man meldet sich am Portal als Systemadministrator (host) an.

Im Systemverwalter wählt man nun den Menüpunkt SQL aus.

image

Dort kopiert man das nachfolgende SQL Script in die Eingabemaske:

IF EXISTS (select * from dbo.sysobjects where id = object_id(N'{databaseOwner}{objectQualifier}DMX_GetExtensionsByPortal') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
DROP PROCEDURE {databaseOwner}{objectQualifier}DMX_GetExtensionsByPortal
GO 

CREATE PROCEDURE {databaseOwner}{objectQualifier}DMX_GetExtensionsByPortal
    @PortalId Int
AS 

SELECT
    {databaseOwner}{objectQualifier}DMX_Extensions.[AccessRights],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Addon],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ControlToLoad],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Custom],
    {databaseOwner}{objectQualifier}DMX_Extensions.[DownloadUrl],
    {databaseOwner}{objectQualifier}DMX_Extensions.[EntryTypes],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ExtensionKey],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Icon16],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Icon32],
    {databaseOwner}{objectQualifier}DMX_Extensions.[IsPrivate],
    {databaseOwner}{objectQualifier}DMX_Extensions.[MimeType],
    {databaseOwner}{objectQualifier}DMX_Extensions.[PortalId],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ResourceFile],
    {databaseOwner}{objectQualifier}DMX_Extensions.[SettingsControl],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ViewByDefault], 
    {databaseOwner}{objectQualifier}DMX_Addons.Description AS AddonsDescription, 
    {databaseOwner}{objectQualifier}vw_PortalsDefaultLanguage.Description AS PortalsDescription
FROM
    {databaseOwner}{objectQualifier}vw_PortalsDefaultLanguage INNER JOIN {databaseOwner}{objectQualifier}DMX_Addons 
     INNER JOIN {databaseOwner}{objectQualifier}DMX_Extensions ON {databaseOwner}{objectQualifier}DMX_Addons.AddonKey = 
     {databaseOwner}{objectQualifier}DMX_Extensions.Addon ON {databaseOwner}{objectQualifier}vw_PortalsDefaultLanguage.PortalID = 
    {databaseOwner}{objectQualifier}DMX_Extensions.PortalId
WHERE
    {databaseOwner}{objectQualifier}DMX_Extensions.PortalId = @PortalId 

GO

achtet darauf das die Checkbox “Run as script” markiert ist betätigt den Link “Execute”

Das war’s auch schon

Wer übrigens mehr über den Hintergrund zu diesem Problem wissen will, kann in meinem Beitrag DotNetNuke 5.2.0 – Breaking Changes – Part I – Der Begin der echten Portal Lokalisierung mehr erfahren.

SQL – Größe aller Tabellen einer Datenbank

Beim stöbern in meinen SQL Skripten bin ich gerade wieder auf das hier nachfolgend aufgeführte Skript zur Ausgabe der “Größe aller Tabellen einer Datenbank” gestoßen.

Da ich sicherlich nicht der einzige bin, der diese Informationen einer Datenbank hin und wieder benötigt, veröffentliche ich hier das Skript mit der Hoffnung dass es jemand gebrauchen kann.

SET NOCOUNT ON
CREATE TABLE #TableSpace 
(
	Rows int, 
	DataSpaceUsed int, 
	IndexSpaceUsed int
)
DECLARE @TableSpace table
(
	TableName varchar(255),
	Rows int, 
	DataSpaceUsed int, 
	IndexSpaceUsed int
)
DECLARE @Rows int, @DataSpaceUsed int, @IndexSpaceUsed int
DECLARE @TableName varchar(255)
DECLARE Table_Cursor CURSOR FOR
SELECT	user_name(o.uid) + '.' + o.name AS table_name
FROM	dbo.sysobjects o, dbo.sysindexes i 
WHERE	OBJECTPROPERTY(o.id, N'IsTable') = 1 
	AND i.id = o.id 
	AND i.indid < 2 
	AND o.name NOT LIKE N'#%' 
	AND xtype = 'U'
ORDER BY 1
OPEN Table_Cursor
---------------------------------
--Set Data
FETCH NEXT FROM Table_Cursor INTO @TableName
INSERT INTO #TableSpace (Rows, DataSpaceUsed, IndexSpaceUsed)
EXEC sp_MStablespace @TableName
SELECT	@Rows = Rows, 
	@DataSpaceUsed = DataSpaceUsed,
	@IndexSpaceUsed = IndexSpaceUsed
FROM	#TableSpace
INSERT INTO @TableSpace (TableName, Rows, DataSpaceUsed, IndexSpaceUsed)
VALUES (@TableName, @Rows, @DataSpaceUsed, @IndexSpaceUsed)
DELETE FROM #TableSpace
--------------------------------
WHILE @@FETCH_STATUS = 0


    BEGIN
    	---------------------------------
    	--Set Data
    	FETCH NEXT FROM Table_Cursor INTO @TableName
    	
    	INSERT INTO #TableSpace (Rows, DataSpaceUsed, IndexSpaceUsed)
    	EXEC sp_MStablespace @TableName
    	
    	SELECT	@Rows = Rows, 
    		@DataSpaceUsed = DataSpaceUsed,
    		@IndexSpaceUsed = IndexSpaceUsed
    	FROM	#TableSpace
    	
    	INSERT INTO @TableSpace (TableName, Rows, DataSpaceUsed, IndexSpaceUsed)
    	VALUES (@TableName, @Rows, @DataSpaceUsed, @IndexSpaceUsed)
    	
    	DELETE FROM #TableSpace
    	--------------------------------
END

CLOSE Table_Cursor
DEALLOCATE Table_Cursor
DROP TABLE #TableSpace
SELECT * 
FROM @TableSpace
ORDER BY Rows DESC

Über die Herkunft dieses Skripts (ich weiß dass ich zumindest die Idee von irgendwoher hatte) bin ich mir nicht mehr sicher. Eine gerade durchgeführte Recherche im Internet hat mir auch keinen direkten Aufschluss gegeben woher ich das Skript oder die Idee dazu hatte.

Sollte also jemand die Herkunft kennen, bitte einfach per Kommentar posten.

Microsoft SQL Server Management Studio – Spaltenüberschriften fehlen beim kopieren der Abfrageergebnisse

Wer kennt das nicht, mal schnell eine Abfrage auf eine SQL Datenbank mit dem Microsoft SQL Server Management Studio gemacht, Ergebnis der Abfrage markiert und dann mit Copy / Paste das Abfrageergebnis einfach in Excel eingefügt.

Soweit geht das auch ohne Probleme. Störend dabei ist nur, dass die Spaltenüberschriften (Spaltenheader) nicht mit kopiert werden und man diese wenn man sie benötigt manuell übertragen muss.

Wenn man das Ergebnis mit Copy / Paste als Text in einen Texteditor einfügt, sind die Spaltenheader übrigens vorhanden.

Das kann aber auch in Excel so sein.

Das Microsoft SQL Server Management Studio besitzt einen Optionsschalter mit dem man dieses Verhalten steuern kann.

Der Optionsschalter befindet sich wie nachfolgend dargestellt unter Extras –> Optionen

image

Man muss einfach nur das Häkchen bei der Option:

Spaltenheader beim kopieren oder Speichern der Ergebnisse einschließen.

setzen und schon wird auch der Spaltenheader kopiert.

Übrigens kann man das Verhalten beim einfügen in einen Texteditor genau so steuern, nur da ist die Default Einstellung eben; das Häkchen ist gesetzt (siehe Abbildung).

image

T-SQL – Select * from < table > where < datetimeField > < 2007

Da mein Hauptgeschäft nicht in der Erstellung von SQL Abfragen liegt, kommt es immer wieder vor, dass ich nach ein und der gleichen Lösung für ein Problem immer wieder mal recherchieren muss, da ich mir die Lösungen nicht (bzw. nicht immer) merken kann.

Dieser Beitrag fällt unter diese Kategorie (Und nachdem ich es nun aufgeschrieben habe, werde ich es wohl nie mehr vergessen smile_shades, na dann hätte es ja was genutzt dies hier aufzuschreiben.).

Nun aber zum eigentlichen Problem bzw. zur Lösung:

Ich weiß nicht wie oft ich schon mal schnell eine SQL Abfrage machen musste, die alle Daten anzeigt, oder löscht oder was auch sonst immer, welches entweder vor, nach oder in einem bestimmten Jahr einen Eintrag in einem datetime Feld enthält

Bei eigenen Tabellen Entwürfen häufig das Feld „Created“, oder „LastChange“ – ein Datenbank Feld mit dem Datentyp datetime.

Nun ist die Abfrage „Select * from  <table> where <datetimeField>  < 2007“ thumbs_down wie in der Überschrift verwendet syntaktisch nicht falsch, also es wird kein SQL Fehler erzeugt, aber es wird auch nicht das gewünschte Ergebnis angezeigt.

So wie die Abfrage aufgebaut ist, wird das Ergebnis leer sein, da keiner der datetime Werte kleiner sein dürfte als der Wert 2007.

Die korrekte Abfrage (besser gesagt, eine korrekte Möglichkeit) dafür sieht wie folgt aus:

Select * from  <table> where DatePart(year,<datetimeField>)  <= 2007 thumbs_up

Hier wird nun nur nach dem Jahr innerhalb des datetime Ausdrucks verglichen und der Vergleich mit 2007 ist dann richtig.

Mehr über DatePart auf MS TechNet

SQL Profis mögen mir verzeihen wenn ich bei den verwendeten Begriffen nicht immer ganz getroffen habe, aber wie gesagt, SQL Abfragen ist nicht unbedingt mein Spezialgebiet. T-SQL – Select * from < table > where < datetimeField > < 2007 weiterlesen