Thomas Bandt

Über mich | Kontakt | Archiv

SQL Server Express - Es hätte so schön sein können ...

Als ich vor gut anderthalb Jahren das erste Mal vom SQL Server Express gehört habe, war ich eigentlich ganz angetan - schließlich lesen sich die Möglichkeiten erstmal hervorragend:

Da hier bei uns in der Firma seit Jahren Microsoft Access als als Standard für Kleinsts-Websites zum Einsatz kommt (bzw. kam), klang das zumindest so, als gäbe es dafür nun endlich einen würdigen Nachfolger. Denn vor allem das letzte genannte Kriterium bietet so kaum ein anderes, mit Access vergleichbares oder höherwertiges, System - nämlich die Möglichkeit Datenbankdateien einfach rumzukopieren.

Allerdings wurden meine Erwartungen, die in der Theorie durchaus erfüllt werden, in der Praxis sehr schnell enttäuscht. Praxis bedeutet hier nicht einmal der Livebetrieb am Webserver, soweit kam es nie, sondern bereits der Entwicklungsprozess. Zwar kann man die Datenbankdateien tatsächlich hin- und her kopieren, aber leider nicht wirklich auch mit mehreren Anwendungen, wie im Entwicklungsprozess üblich, gleichzeitig benutzen.

So ist es quasi unmöglich die Datenbank sowohl in Visual Studio als auch Management Studio Express geöffnet zu haben, und gleichzeitig noch die Website damit lokal zu testen.

Die Ursache ist hier beschrieben, und liegt im Einsatz von User Instanzen:

"User Instance Limitations

The unique User Instance architecture introduces some functional limitations as follows:

Common Issues

The User Instance architecture sometimes leads to confusion when databases don't behave the way we are accustomed to. Most of these issues are related to the database files that get attached to the user instance and how they are handled. Following are the more common issues.

  1. The user instance cannot attach the database because the user does not have the required permissions. The user instance executes in the context of the user who opened the connection—not the normal SQL Server service account. The user who opened the user instance connection must have write permissions on the .mdf and .ldf files that are specified in the AttachDbFilename option of the connection string. One common issue occurs when working with the Visual Web Designer. The application connects to a user instance database from the Visual Studio integrated development environment (IDE) and then fails to connect when the database is opened by the Web page. When the ASP page opens the database it is generally running as ASPNET. If ASPNET does not have write permissions on the database files, the connection fails.

    Another common issue is when you open a database file successfully when the database is attached to the SQL Server Express instance, but fails when you try to open it from the Visual Studio IDE. This might occur because the SQL Server Express instance is running as "NT AUTHORITY\NETWORK SERVICE," while the IDE is running as you. Therefore, the permissions may not work.

  2. A variation of this issue is when the user that opens the user instance connection has read permissions on the database files but does not have write permissions. In this case, SQL Server attaches the database as a READ_ONLY database. If you get a message saying that the database is opened as read only, you need to change the permissions on the database file.
  3. The other main issue with user instances occurs because SQL Server opens database files with exclusive access. This is necessary because SQL Server manages the locking of the database data in its memory. Thus, if more than one SQL Server instance has the same file open, there is the potential for data corruption. If two different user instances use the same database file, one instance must close the file before the other instance can open it. There are two common ways to close database files, as follows.
    • User instance databases have the Auto Close option set so that if there are no connections to a database for 8-10 minutes, the database shuts down and the file is closed. This happens automatically, but it can take a while, especially if connection pooling is enabled for your connections.
    • Detaching the database from the instance by calling sp_detach_db will close the file. This is the method Visual Studio uses to ensure that the database file is closed when the IDE switches between user instances. For example, you are using the IDE to design a data-enabled Web page. You press F5 to run the application. The IDE detaches the database so that ASP.NET can open the database files. If you leave the database attached to the IDE and try to run the ASP page from your browser, ASP.NET cannot open the database because the file is still in use by the IDE."

Was bedeutet das?

Das heißt im Prinzip, dass sich SQL Server Express Datenbanken nur wirklich verwenden lassen, wenn man mit Ihnen wie mit der großen Version arbeitet, d.h. wenn man sie an eine laufende Server-Instanz anhängt.

Vorbei "der Traum", dass man die Datenbankdateien einfach lokal entwickeln und dann via XCopy deployen kann - klar, in der Theorie geht es natürlich noch immer, aber praktisch ist es quasi ausgeschlossen.

Eigentlich schade, dass Microsoft das Ganze dann doch wieder so extrem eingeschränkt hat und keinen vernünftigen Zugriffsweg auf File- und nicht Server-Instanz-Basis geschaffen hat.

Kommentare

  1. no@spam.com (Basil Brunner) schrieb am Donnerstag, 30. März 2006 22:42:00 Uhr:

    Ganz so schlimm seh ich das nun auch wieder nicht.<br /><br />Was die Entwicklung betrifft, da hast du recht. Ich persönlich hänge die Datenbank-Datei immer an eine Instanz an.<br /><br />Das Deployment finde ich hingegen nicht schlecht. Dort gibt es meisst sowieso nur ein Prozess, der die Datenbank-Datei benötigt und das ist meine Applikation. Wenn nur bereits mehrere Hoster SQL Server 2005 anbieten würden...


« Zurück  |  Weiter »