-
ACHTUNG - NEUES BLOG
Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
|
SQL Server 2005: Output-Klausel
21.04.06 - SQL Server Beitrag von Norbert Eder| | Eines der neuen Features des SQL Server 2005 ist die OUTPUT-Klausel, die Transact-SQL um eine nützliche Funktion erweitert.
Durch die Angabe der OUTPUT-Klausel können in INSERT, UPDATE und DELETE Anweisungen, die betroffenen Datensätze, oder Teile davon (beispielsweise die Primary-Key-Werte) zurückgegeben werden.
Dies ist beispielsweise bei einem INSERT sehr interessant, wenn die vergebene ID im weiteren Ablauf benötigt wurde. Diese konnte bisher via SELECT @@Identity bezogen werden. Danach musste ein weiteres SELECT-Statement abgesetzt werden, um den Datensatz zu erhalten. Durch die OUTPUT-Klausel ist dies nicht mehr notwendig. Die Ergebnisse werden sofort zurückgeliefert, sofern gewünscht.
Beispiel
USE AdventureWorks;
GO
DELETE tUser
OUTPUT deleted.*
WHERE ID = 7;
GO
Dieses Beispiel löscht den Datensatz mit der ID 7 aus der Tabelle tUser und gibt den gesamten Datensatz zurück. Es können jedoch auch nur einzelne Felder zurückgeliefert werden:
USE AdventureWorks;
GO
DELETE tUser
OUTPUT deleted.ID, deleted.Firstname, deleted.Lastname
WHERE ID = 7;
GO
Hier würden nur die ID, der Vorname und der Nachname als ResultSet zurückgegeben werden.
Wie kann dies unter dem .NET Framework benutzt werden? Es verhält sich sehr einfach. Die einzelnen Statements werden mit einem Command-Objekt (beispielsweise SqlCommand) abgesetzt. Im Falle von INSERT, UPDATE bzw. DELETE Abfragen wird dazu die Methode ExecuteNonQuery verwendet. Wird nun die OUTPUT-Klausel verwendet, ist anstatt der Methode ExecuteNonQuery beispielsweise die Methode ExecuteReader zu verwenden. Mit dem zurückgegebenen DataReader kann durch die einzelnen Datensätze iteriert werden.
Referenzen
[1] MSDN
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Zurück vom SQL Server 2005 Development Summit
14.04.06 - SQL Server Beitrag von Norbert EderSQL Server 2005: Erstellung einer Replikation
12.02.06 - SQL Server Beitrag von Norbert EderSQL Server 2005: Managed Code
12.02.06 - SQL Server Beitrag von Norbert EderSQL Server 2005: Custom Datatypes
12.02.06 - SQL Server Beitrag von Norbert EderConnectionstrings unter C#, VB.NET
27.01.06 - SQL Server Beitrag von Norbert Eder| | Immer wieder wird nach den richtigen Connectionstrings für die unterschiedlichsten Datenbank-Systeme gefragt. Daher mein Tipp: einfach auf http://www.connectionstrings.com/ nachsehen. Da sollte das meiste zu finden sein.
Und wie wird dieser dann in C# bzw. VB.NET verwendet? Gut, hierfür kann ich ein kleines Beispiel geben (gilt für den Microsoft SQL Server):
C#
using System.Data.SqlClient;
...
SqlConnection conn = new SqlConnection();
conn.ConnectionString = "Data Source=(local);" +
"Initial Catalog=MyDatabaseName;" +
"Integrated Security=SSPI";
conn.Open();
VB.NET
Imports System.Data.SqlClient
...
Dim conn As SqlConnection = New SqlConnection()
conn.ConnectionString = "Data Source=(local);" & _
"Initial Catalog=MyDatabaseName;" & _
"Integrated Security=SSPI"
oSQLConn.Open()
Dies gilt nun für den Microsoft SQL Server, der lokal installiert ist. Für einen SQL Server der auf einem anderen Rechner installiert ist, muss lediglich der Connectionstring ausgetauscht und angepasst werden. Die entsprechenden Connectionstrings sind im oben angeführten Link zu finden.
Noch als Zusatzinfo: Die Beispiele funktionieren sowohl bei einem SQL Server 2000, als auch beim SQL Server 2005.
| | | 19 Kommentare
- 16930 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
SA User unter SQLServer 2005 umbenennen
19.01.06 - SQL Server Beitrag von Norbert Eder| | Unter dem Microsoft SQL Server 2000 ist es ja nicht möglich, dan sa User umzubenennen bzw. zu deaktivieren. Der SQL Server 2005 bietet allerdings diese Möglichkeit. Durchgeführt können diese beiden Aktionen mit ALTER LOGIN werden.
ALTER LOGIN sa DISABLE;
ALTER LOGIN sa WITH NAME = [sys-admin];
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
SQL Server 2000: Felder zur Replikation hinzufügen
13.01.06 - SQL Server Beitrag von Norbert Eder| | In manchen Fällen ist es notwendig, zu einer Datenbank neue Felder hinzuzufügen. Wird nun diese Datenbank auf einen weiteren Server repliziert ergeben sich hier die einen oder anderen Probleme.
Die beste Erfahrung habe ich mit der Stored Procedure sp_repladdcolumn gemacht. Mit Hilfe dieser Stored Procedure wird das Feld in der zu replizierenden Datenbank (Publication) eingetragen und zur Replikation hinzugefügt.
Wichtig hierbei ist, dass die Replikation vor der Änderung gestoppt werden muss.
exec sp_repladdcolumn
@source_object = 'Tabellenname',
@column = 'Spaltenname',
@typetext = 'float NULL',
@publication_to_add = 'all'
Danach muss der Snapshot erneut erstellt und nach Abschluss dessen die Replizierung wieder gestartet werden.
Mit der Stored Procedure sp_addarticle kann übrigens eine neue Tabelle erstellt werden, die ebenfalls zur Replizierung hinzugefügt wird.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Connection-Probleme zu SQL Server 2005 Express?
11.12.05 - SQL Server Beitrag von Norbert Eder| | Eventuell die nette Meldung provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server?
Die Lösung ist einfach: Im ConnectionString wurde einfach der Instanzname bei der Data Source vergessen. Beispielsweise 127.0.0.1\Instanzname angeben und schon funktioniert alles wie gewollt.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
SQL Server Replizierung: Alt oder doch neu?
09.12.05 - SQL Server Beitrag von Norbert Eder| | Wer sich derzeit mit den Gedanken über eine SQL Server Replizierung spielt und sich nicht sicher ist, ob er den altbewährten SQL Server 2000 oder dann doch den neuen 2005er nehmen soll, dann kann ihm geholfen werden.
Werden in Zukunft Änderungen an Tabellen etc. vorgenommen?
Wenn nein, dann sehe ich kein Problem bei der Verwendung der 2000er-Version. Handelt es sich dabei allerdings um ein wachsendes System, d.h. die Struktur der Tabellen etc. kann bzw. wird sich verändern, dann rate ich eindeutig zum 2005er.
Der Grund liegt darin, dass Änderungen an der Tabellenstruktur im SQL Server 2000 nur schwer nachgezogen werden kann. Wird beispielsweise im Verteiler (der Server, der die Daten an seine Abonennten verteilt) eine neue Tabelle angelegt, muss die Publikation, als auch die Abonnenten am Verteiler gelöscht und neu erstellt werden. Ändern sich nur einzelne Datenfelder, können diese nur mit der Stored Procedure sp_repladdcolumn zur Replikation hinzugefügt werden. Dies ist auf Dauer doch recht mühsam. Der SQL Server 2005 bietet diese Einschränkungen nicht mehr.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Zurück Weiter
|
|
|
|
|
|
|
