Skip to content

5. Fallstudie mit Oracle Database Express Edition 11g Release 2

5.1. Installation der Tools

Folgende Tools müssen installiert werden:

  • das DBMS: [http://www.oracle.com/technetwork/products/express-edition/downloads/index.html];
  • ein Verwaltungstool: EMS SQL Manager for Oracle Freeware [http://www.sqlmanager.net/fr/products/oracle/manager/download];
  • ein Oracle-Client für .NET: ODAC 11.2 Release 5 (11.2.0.3.20) mit Oracle Developer Tools für Visual Studio: [http://www.oracle.com/technetwork/developer-tools/visual-studio/downloads/index.html].

In den folgenden Beispielen hat der Benutzer „system“ das Passwort „system“.

Starten Sie Oracle [1] und anschließend das Tool [SQL Manager Lite for Oracle], mit dem wir das DBMS verwalten werden [2].

  • In [3] stellen wir eine Verbindung zu einer bestehenden Datenbank her;
  • In [4] verwenden wir den Oracle XE-Dienst für die Verbindung;
  • In [5] geben wir den Namen der XE-Datenbank an;
  • in [6] melden wir uns als system/system an;
  • In [7] schließen wir den Assistenten ab;
  • In [8] stellen wir eine Verbindung zur Datenbank her;
  • In [9] sind wir verbunden;
  • Da wir uns als Benutzer „system/system“ angemeldet haben, der über erweiterte Berechtigungen verfügt, können wir beispielsweise Benutzer verwalten [10];
  • Erstellen Sie in [11] einen neuen Benutzer;
  • in [12] erhält der Benutzer den Namen [RDVMEDECINS-EF];
  • in [13] erhält er das Passwort rdvmedecins;
  • In [14] wird die Benutzererstellung bestätigt;
  • in [15] wurde der Benutzer erstellt;
  • in [16] ist der Benutzer [RDVMEDECINS-EF] auch ein Datenbankschema;
  • in [17] verfügt der angelegte Benutzer nicht über ausreichende Berechtigungen. Wir erteilen diese über ein SQL-Skript;
  • in [18] wird das Skript ausgeführt;
  • in [19] versuchen wir, uns als [RDVMEDECINS-EF] anzumelden, um zu sehen, was er tun kann. Dazu registrieren wir zunächst eine neue Datenbank in [EMS Manager];
  • in [19] melden wir uns über den XE-Dienst an;
  • In [20] melden wir uns als RDVMEDECINS-EF / rdvmedecins an;
  • In [21] weisen wir einen Alias zu, der den Namen des angemeldeten Benutzers widerspiegelt;
  • in [22] stellen wir mit den bereitgestellten Anmeldedaten eine Verbindung zu Oracle her;
  • In [22] haben wir uns erfolgreich angemeldet;
  • In [23] versuchen wir, eine Tabelle im Schema [RDVMEDECINS-EF] anzulegen;
  • in [24] definieren wir eine Tabelle;
  • In [25] überprüfen wir ihre Definition;
  • In [26] wurde die Tabelle erstellt. Wir löschen sie;
  • In [27] wurde sie gelöscht.

Da wir nun über einen Benutzer mit ausreichenden Berechtigungen verfügen, erstellen wir das VS 2012-Projekt, das die Tabellen im Schema [RDVMEDECINS-EF] auf der Grundlage der Entitätsdefinitionen anlegt.

5.2. Erstellen der Datenbank aus den Entitäten

Zunächst duplizieren wir den Projektordner [RdvMedecins-SqlServer-01] in [RdvMedecins-Oracle-01] [1]:

  • In [2] entfernen wir in VS 2012 das Projekt [RdvMedecins-SqlServer-01] aus der Lösung;
  • in [3] wurde das Projekt entfernt;
  • in [4] fügen wir ein weiteres hinzu. Dieses stammt aus dem Ordner [RdvMedecins-Oracle-01], den wir zuvor erstellt haben;
  • in [5] heißt das geladene Projekt [RdvMedecins-SqlServer-01];
  • in [6] ändern wir seinen Namen in [RdvMedecins-Oracle-01]
  • in [7] fügen wir der Lösung ein weiteres Projekt hinzu. Dieses stammt aus dem Ordner [RdvMedecins-SqlServer-01] des Projekts, das wir zuvor aus der Lösung entfernt haben;
  • in [8] wurde das Projekt [RdvMedecins-SqlServer-01] wieder zur Lösung hinzugefügt.

Das Projekt [RdvMedecins-Oracle-01] ist identisch mit dem Projekt [RdvMedecins-SqlServer-01]. Wir müssen einige Änderungen vornehmen. In [App.config] ändern wir die Verbindungszeichenfolge und die [DbProviderFactory], die an jedes DBMS angepasst werden müssen.


<!-- connection chain on base -->
  <connectionStrings>
    <add name="monContexte" connectionString="Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=XE)));User Id=RDVMEDECINS-EF;Password=rdvmedecins;" providerName="Oracle.DataAccess.Client" />
  </connectionStrings>
  <!-- the factory provider -->
  <system.data>
    <DbProviderFactories>
      <remove invariant="Oracle.DataAccess.Client" />
      <add name="Oracle Data Provider for .NET" invariant="Oracle.DataAccess.Client" description="Oracle Data Provider for .NET" type="Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
    </DbProviderFactories>
  </system.data>
  • Zeile 3: Benutzername und Passwort;
  • Zeilen 6–11: die DbProviderFactory. Zeile 9 verweist auf eine DLL [Oracle.DataAccess], die wir nicht haben. Wir können sie über NuGet [1] beziehen:
  • Geben Sie in [2] das Stichwort „oracle“ in das Suchfeld ein;
  • Wählen Sie in [3] das entsprechende Paket [Oracle Data Provider] aus. Dies ist der ADO.NET-Konnektor von Oracle;
  • in [4] wird die Referenz hinzugefügt;
  • in [5], in [App.config], müssen Sie die richtige Version der DLL angeben. Diese finden Sie in den Eigenschaften der Datei.

In der Datei [Entities.cs] müssen Sie das Schema der zu generierenden Tabellen anpassen. Das verwendete Schema ist der Name des Benutzers, dem die Tabellen gehören.


  [Table("MEDECINS", Schema = "RDVMEDECINS-EF")]
  public class Medecin : Personne
  {...}
 
  [Table("CLIENTS", Schema = "RDVMEDECINS-EF")]
  public class Client : Personne
  {...}
 
  [Table("RVS", Schema = "RDVMEDECINS-EF")]
  public class Rv
  {...}
 
  [Table("CRENEAUX", Schema = "RDVMEDECINS-EF")]
  public class Creneau
  {...}

Wir konfigurieren den Projekt-Build:

  • In [1] geben wir der zu generierenden Assembly einen anderen Namen;
  • in [2] geben wir außerdem einen anderen Standard-Namespace an;
  • in [3] geben wir das auszuführende Programm an.

Zu diesem Zeitpunkt gibt es keine Kompilierungsfehler. Führen wir das Programm [CreateDB_01] aus. Wir erhalten die folgende Ausnahme:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Exception non gérée : System.Data.MetadataException: Le schéma spécifié n'est pas valide. Erreurs :
(11,6) : erreur 0040: Le type rowversion n'est pas qualifié avec un espace de noms ou un alias. Seuls les types primitifs peuvent être utilisés sans qualification.
(23,6) : erreur 0040: Le type rowversion n'est pas qualifié avec un espace de noms ou un alias. Seuls les types primitifs peuvent être utilisés sans qualification.
(33,6) : erreur 0040: Le type rowversion n'est pas qualifié avec un espace de noms ou un alias. Seuls les types primitifs peuvent être utilisés sans qualification.
(43,6) : erreur 0040: Le type rowversion n'est pas qualifié avec un espace de noms ou un alias. Seuls les types primitifs peuvent être utilisés sans qualification.
   à System.Data.Metadata.Edm.StoreItemCollection.Loader.ThrowOnNonWarningErrors
()
   ...
   à RdvMedecins_01.CreateDB_01.Main(String[] args) dans d:\data\istia-1213\c#\d
vp\Entity Framework\RdvMedecins\RdvMedecins-Oracle-01\CreateDB_01.cs:ligne 15

Wir erinnern uns, dass wir denselben Fehler bereits bei MySQL hatten. Dies hängt mit dem Typ des Timestamp-Feldes in den Entitäten zusammen. Wir nehmen dieselbe Änderung vor. In den Entitäten ersetzen wir die drei Zeilen


    [Column("TIMESTAMP")]
    [Timestamp]
    public byte[] Timestamp { get; set; }

mit folgendem Inhalt:


    [ConcurrencyCheck]
    [Column("VERSIONING")]
    public int? Versioning { get; set; }

Wir ändern daher den Spaltentyp von </span>**<span style="color: #000000">byte[] in int?**. Zur Erinnerung: Sowohl bei SQL Server als auch bei MySQL wurde der Spalte der Tabelle, die zur Verwaltung der Zugriffsparallelität diente, bei jedem Einfügen oder Ändern einer Zeile vom DBMS ein Wert zugewiesen. Von nun an verwenden wir ein Entitätsfeld vom Typ Integer. Im DBMS werden wir Stored Procedures einsetzen, um diesen Integer bei jedem Einfügen oder Ändern einer Zeile um eins zu erhöhen.

Wir nehmen die oben genannte Änderung für alle vier Entitäten vor und führen die Anwendung anschließend erneut aus. Daraufhin erhalten wir die folgende Fehlermeldung:

1
2
3
4
5
6
Exception non gérée : System.Data.DataException: An exception occurred while initializing the database. See the InnerException for details. ---> System.Data.ProviderIncompatibleException: DeleteDatabase n'est pas pris en charge par le fournisseur.
   à System.Data.Common.DbProviderServices.DbDeleteDatabase(DbConnection connection, Nullable`1 commandTimeout, StoreItemCollection storeItemCollection)
   ...
   à System.Data.Entity.Internal.LazyInternalContext.InitializeDatabase()
   à RdvMedecins_01.CreateDB_01.Main(String[] args) dans d:\data\istia-1213\c#\d
vp\Entity Framework\RdvMedecins\RdvMedecins-Oracle-01\CreateDB_01.cs:ligne 15

Zeile 1 weist darauf hin, dass der Oracle-ADO.NET-Konnektor die vorhandene Datenbank nicht löschen kann. Schauen wir uns an, was hier vor sich geht. Der Code in [CreateDB_01.cs] lautet wie folgt:


using System;
using System.Data.Entity;
using RdvMedecins.Models;
 
namespace RdvMedecins_01
{
  class CreateDB_01
  {
    static void Main(string[] args)
    {
      // create the database
      Database.SetInitializer(new RdvMedecinsInitializer());
      using (var context = new RdvMedecinsContext())
      {
        context.Database.Initialize(false);
      }
    }
  }
}

Zeile 15 löst die Ausführung der Klasse [RdvMedecinsInitializer] (Zeile 12) aus. Diese Klasse sieht wie folgt aus:


  public class RdvMedecinsInitializer : DropCreateDatabaseAlways<RdvMedecinsContext>

Sie leitet sich von der Klasse [DropCreateDatabaseAlways] ab, die versucht, die Datenbank zu löschen und anschließend neu zu erstellen. Wir ändern die Klassendefinition wie folgt:


  public class RdvMedecinsInitializer : CreateDatabaseIfNotExists<RdvMedecinsContext>

Die Datenbank wird nur erstellt, wenn sie nicht existiert. Wir führen [CreateDB_01.cs] erneut aus, und es treten keine Fehler mehr auf. In [EMS Manager] sehen wir jedoch, dass die Datenbank [RDVMEDECINS-EF] leer bleibt. Da EF 5 eine vorhandene Datenbank gefunden hat, hat es nichts unternommen. Es wird nur aktiv, wenn die Datenbank nicht existiert. Von da an befinden wir uns in einer Endlosschleife. Tatsächlich lautet die Verbindungszeichenfolge zum DBMS wie folgt:


  <connectionStrings>
    <add name="monContexte" connectionString="Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=XE)));User Id=RDVMEDECINS-EF;Password=rdvmedecins;" providerName="Oracle.DataAccess.Client" />
</connectionStrings>

Zeile 2: Die Verbindungszeichenfolge verwendet einen Benutzernamen anstelle eines Datenbanknamens. Dieser Benutzer muss vorhanden sein.

Wir müssen daher die Datenbank [RDVMEDECINS-EF] manuell mit dem Tool [EMS Manager for Oracle] anlegen. Wir werden nicht jeden Schritt beschreiben, sondern nur die wichtigsten.

Die Oracle-Datenbank sieht wie folgt aus:

Die Tabellen

Die verschiedenen Tabellen verfügen über die Primär- und Fremdschlüssel, die diese Tabellen bereits in den beiden vorherigen Beispielen hatten. Die Fremdschlüssel sind ausdrücklich mit dem Attribut ON DELETE CASCADE versehen.

Sequenzen

Wir haben hier Oracle-Sequenzen erstellt. Dabei handelt es sich um Generatoren für fortlaufende Nummern. Es gibt insgesamt 5 davon [1].

  • In [2] sehen wir die Eigenschaften der Sequenz [SEQUENCE_CLIENTS]. Sie generiert fortlaufende Zahlen in Schritten von 1, beginnend bei 1 bis zu einem sehr großen Wert.

Alle Sequenzen basieren auf demselben Modell.

  • [SEQUENCE_CLIENTS] wird verwendet, um den Primärschlüssel für die Tabelle [CLIENTS] zu generieren;
  • [SEQUENCE_DOCTORS] wird zur Generierung des Primärschlüssels für die Tabelle [DOCTORS] verwendet;
  • [SEQUENCE_SLOTS] wird verwendet, um den Primärschlüssel für die Tabelle [SLOTS] zu generieren;
  • [SEQUENCE_RVS] wird verwendet, um den Primärschlüssel für die Tabelle [RVS] zu generieren;
  • [SEQUENCE_VERSIONS] wird verwendet, um die Werte für die [VERSIONING]-Spalten in allen Tabellen zu generieren.

Trigger

Ein Trigger ist eine Prozedur, die vom DBMS vor oder nach einem Ereignis (Insert, Update, Delete) in einer Tabelle ausgeführt wird. Wir haben 8 davon [1]:

 

Sehen wir uns den DDL-Code für den Trigger [TRIGGER_PK_CLIENTS] an, der den Primärschlüssel der Tabelle [CLIENTS] füllt:

1
2
3
4
5
6
7
8
CREATE TRIGGER "RDVMEDECINS-EF".TRIGGER_PK_CLIENTS
 BEFORE INSERT
 ON "RDVMEDECINS-EF".CLIENTS
REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW
BEGIN
        SELECT SEQUENCE_CLIENTS.NEXTVAL INTO :new.ID from DUAL;
END;
/
  • Zeilen 1–5: Vor jeder INSERT-Operation in der Tabelle [CLIENTS];
  • Zeile 6: Die Spalte [ID] erhält den nächsten Wert aus der Sequenz [SEQUENCE_CLIENTS]. Der Primärschlüssel erhält somit fortlaufende Werte, die von der Sequenz bereitgestellt werden.

Die Trigger [TRIGGER_PK_MEDECINS, TRIGGER_PK_CRENEAUX, TRIGGER_PK_RVS] funktionieren auf ähnliche Weise.

Sehen wir uns den DDL-Code für den Trigger [TRIGGER_VERSIONS_CLIENTS] an, der die Spalte [VERSIONING] der Tabelle [CLIENTS] füllt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
CREATE TRIGGER "RDVMEDECINS-EF".TRIGGER_VERSION_CLIENTS
 BEFORE INSERT OR UPDATE
 OF
  VERSIONING
 ON "RDVMEDECINS-EF".CLIENTS
REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW
BEGIN
        SELECT SEQUENCE_VERSIONS.NEXTVAL INTO :new.VERSIONING from DUAL;
END;
/
  • Zeilen 1–2: Vor jeder INSERT- oder UPDATE-Operation an der Tabelle [CLIENTS];
  • Zeile 8: Die Spalte [VERSIONING] erhält den nächsten Wert aus der Sequenz [SEQUENCE_VERSIONS]. Die Spalte [VERSIONING] enthält somit fortlaufende Werte, die von der Sequenz bereitgestellt werden.

Die Trigger [TRIGGER_VERSION_MEDECINS, TRIGGER_VERSION_CRENEAUX, TRIGGER_VERSION_RVS] funktionieren auf ähnliche Weise. Die vier [VERSIONING]-Spalten beziehen ihre Werte aus derselben Sequenz.

Das Skript zur Erstellung der Oracle-Datenbanktabellen [RDVMEDECINS-EF] wurde im Ordner [RdvMedecins / databases / oracle] abgelegt. Der Leser kann es laden und ausführen, um die Tabellen zu erstellen.

Sobald dies erledigt ist, können die verschiedenen Programme im Projekt ausgeführt werden. Sie liefern dieselben Ergebnisse wie bei SQL Server, mit Ausnahme des Programms [ModifyDetachedEntities], das aus demselben Grund abstürzt wie bei MySQL. Das Problem wird auf dieselbe Weise behoben. Kopieren Sie einfach das Programm [ModifyDetachedEntities] aus dem Projekt [RdvMedecins-MySQL-01] in das Projekt [RdvMedecins-Oracle-01]. Dies führt dann zu einem neuen Problem:

1
2
3
4
5
6
7
8
9
1-----------------------------
Client [206,x,x,x,616]
2-----------------------------
Client [206,x,x,y,617]

Exception non gérée : System.Data.Entity.Infrastructure.DbUpdateConcurrencyException: Une instruction de mise à jour, d'insertion ou de suppression dans le magasin a affecté un nombre inattendu de lignes (0). Des entités ont peut-être été modifiées ou supprimées depuis leur chargement. Actualisez les entrées ObjectStateManager. ---> System.Data.OptimisticConcurrencyException: Une instruction de mise à jour, d'insertion ou de suppression dans le magasin a affecté un nombre inattendu de lignes (0). Des entités ont peut-être été modifiées ou supprimées depuis leur chargement. Actualisez les entrées ObjectStateManager.
   ...
   à RdvMedecins_01.ModifyDetachedEntities.Main(String[] args) dans d:\data\istia-1213\c#\dvp\Entity Framework\RdvMedecins\RdvMedecins-Oracle-01\ModifyDetachedE
ntities.cs:ligne 56
  • Zeilen 1–4: Der getrennte Client wurde erfolgreich aktualisiert;
  • Zeile 6: eine bekannte Ausnahme. Diese tritt auf, wenn Sie versuchen, eine Entität zu ändern, ohne über die richtige Version zu verfügen. In diesem Fall wollten wir die Entität jedoch nicht ändern, sondern löschen:

      // remove out-of-context entity
      using (var context = new RdvMedecinsContext())
      {
        // here we have a new empty context
        // put client1 in the context in a deleted state
        context.Entry(client1).State = EntityState.Deleted;
        // save the context
        context.SaveChanges();
}

EF 5 weigerte sich, client1 aus der Datenbank zu löschen, da client1 (Zeile 6) nicht dieselbe Version hatte. Bei MySQL war dieses Problem nicht aufgetreten. Wir stellen nach und nach fest, dass die ADO.NET-Konnektoren für verschiedene DBMS geringfügige Unterschiede aufweisen. Wir beheben das Problem wie folgt:


using (var context = new RdvMedecinsContext())
      {
        // here we have a new empty context
        // put client1 in the context to delete it
        context.Clients.Remove(context.Clients.Find(client1.Id));
        // save the context
        context.SaveChanges();
      }

und es funktioniert.

5.3. Mehrschichtige Architektur auf Basis von EF 5

Kehren wir zu unserer Fallstudie zurück, die in Absatz 2 auf Seite 7 beschrieben wurde.

Wir beginnen mit der Erstellung der [DAO]-Datenzugriffsschicht. Dazu duplizieren wir das VS 2012-Konsolenprojekt [RdvMedecins-SqlServer-02] in [RdvMedecins-Oracle-02] [1]:

  • In [2] löschen wir das Projekt [RdvMedecins-SqlServer-02];
  • In [3] fügen wir der Lösung ein bestehendes Projekt hinzu. Wir nehmen es aus dem soeben erstellten Ordner [RdvMedecins-Oracle-02];
  • in [4] hat das neue Projekt denselben Namen wie das gelöschte. Wir werden seinen Namen ändern;
  • In [5] haben wir den Projektnamen geändert;
  • In [6] ändern wir einige seiner Eigenschaften, wie beispielsweise den Namen der Assembly;
  • in [7] wird der Ordner [Models] gelöscht und durch den Ordner [Models] aus dem Projekt [RdvMedecins-Oracle-01] ersetzt. Der Grund dafür ist, dass beide Projekte dieselben Modelle verwenden.
  • in [8] die aktuellen Verweise des Projekts;
  • in [9] wurde der Oracle ADO.NET-Konnektor mithilfe des NuGet-Tools hinzugefügt.

Ersetzen Sie in der Datei [App.config] die SQL-Server-Datenbankinformationen durch die der Oracle-Datenbank. Diese Informationen finden Sie in der Datei [App.config] des Projekts [RdvMedecins-Oracle-01]:


<!-- connection chain on base -->
  <connectionStrings>
    <add name="monContexte" connectionString="Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=XE)));User Id=RDVMEDECINS-EF;Password=rdvmedecins;" providerName="Oracle.DataAccess.Client" />
  </connectionStrings>
  <!-- the factory provider -->
  <system.data>
    <DbProviderFactories>
      <remove invariant="Oracle.DataAccess.Client" />
      <add name="Oracle Data Provider for .NET" invariant="Oracle.DataAccess.Client" description="Oracle Data Provider for .NET" type="Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
    </DbProviderFactories>
  </system.data>

Auch die von Spring verwalteten Objekte ändern sich. Derzeit haben wir:


  <!-- spring configuration -->
  <spring>
    <context>
      <resource uri="config://spring/objects" />
    </context>
    <objects xmlns="http://www.springframework.net">
      <object id="rdvmedecinsDao" type="RdvMedecins.Dao.Dao,RdvMedecins-SqlServer-02" />
    </objects>
</spring>

Zeile 7 verweist auf die Assembly für das Projekt [RdvMedecins-SqlServer-02]. Die Assembly lautet nun [RdvMedecins-Oracle-02].

Damit sind wir bereit, den Test der [DAO]-Schicht auszuführen. Zunächst müssen wir sicherstellen, dass die Datenbank gefüllt ist (mithilfe des Programms [Fill] aus dem Projekt [RdvMedecins-Oracle-01]). Das Testprogramm läuft erfolgreich.

Wir erstellen die DLL des Projekts wie beim Projekt [RdvMedecins-SqlServer-02] und sammeln alle DLLs des Projekts in einem Ordner [lib], der innerhalb von [RdvMedecins-Oracle-02] angelegt wurde. Diese dienen als Referenzen für das nachfolgende Webprojekt [RdvMedecins-Oracle-03].

  

Wir sind nun bereit, die [ASP.NET]-Schicht unserer Anwendung zu erstellen:

Wir beginnen mit dem Projekt [RdvMedecins-SqlServer-03]. Wir duplizieren den Ordner dieses Projekts in [RdvMedecins-Oracle-03] [1]:

  • In [2] öffnen wir mit VS 2012 Express for the Web die Lösung im Ordner [RdvMedecins-Oracle-03];
  • in [3] ändern wir sowohl den Namen der Lösung als auch den Namen des Projekts;
  • in [4] die aktuellen Verweise des Projekts;
  • in [5] löschen wir sie;
  • in [6], um sie durch Verweise auf die DLLs zu ersetzen, die wir gerade in einem [lib]-Ordner innerhalb des Projekts [RdvMedecins-Oracle-02] gespeichert haben.

Nun müssen wir nur noch die Datei [Web.config] ändern. Wir ersetzen ihren aktuellen Inhalt durch den Inhalt der Datei [App.config] aus dem Projekt [RdvMedecins-Oracle-02]. Sobald dies erledigt ist, führen wir das Webprojekt aus. Es funktioniert. Wir dürfen nicht vergessen, die Datenbank zu füllen, bevor wir die Webanwendung ausführen.

https://stahe.github.io
Dieses Tutorial, verfasst von Serge Tahé, wird der Öffentlichkeit unter den Bedingungen der Creative Commons Namensnennung – Nicht kommerziell – Weitergabe unter gleichen Bedingungen 3.0 Unported.