none
ADO.Net - Datenbanktabelle aus DbDataTable erzeugen RRS feed

  • Frage

  • Hallo ihr Cracks,

    Ich hoffe mal, ich bin hier im richtigen Thread. Ich bin erstaunt, dass es keinen speziellen Thread für ADO.Net gibt!

    Ich entwickle gerade eine Persistenzschicht. Ein Ziel dieser Schicht ist natürlich möglichst Datenbankunabhängig zu sein.
    Dies funktioniert mit den managed Providern auch recht gut. Nun stehe ich nun vor der Herausforderung, dass ich aus einer
    im Programm erzeugten und initialisierten DbDataTable eine "echte" Datenbank-Tabelle erzeugen soll. Leider weiss Google doch
    nicht alles und auch die MSDN zeigt hier sehr viel, aber nicht wie man eine DbDataTable persistiert! Geht das überhaupt? :o)

    Hier der C# Code:

    DataSet tempDataSet = new DataSet();
    
    DbDataAdapter tempDataAdapter = 
    DataSourceProvider.ProviderFactory.CreateDataAdapter();
    
    DbCommand dbCommand = 
    DataSourceProvider.CreateDbCommand();
    
    dbCommand.CommandText = 
    "SELECT * FROM KontobewegungTemplate"; //Eine Tabellen deren Struktur in eine neue Tabelle übernommen wird
    
    tempDataAdapter.SelectCommand = dbCommand;
    tempDataAdapter.SelectCommand.Connection.Open();
    
    DataTable[] tempTableMetaInformation =
    tempDataAdapter.FillSchema(tempDataSet, 
    SchemaType.Source, "KontobewegungTemplate");


    DataTable newTable = tempTableMetaInformation[0].Clone(); newTable.TableName = tempKontoBewegung.Tablename; tempDataSet.Tables.Add(newTable); //Wird Tabelle hier angelegt? tempDataSet.AcceptChanges();
    Vielen Dank für Eure Hilfe!

    Viele Grüße
    hmroessler
    Samstag, 16. Januar 2010 22:22

Antworten

  • Hallo Holger,

    der CommandBuilder erzeugt eben das SQL, was teilweise providerspezifisch ist.
    Wobei Du dort schon Probleme bekommst, wenn Du z. B. Identätswerte hast,
    die je nach RDBMS anders erzeugt werden (Identity, Sequence usw.)
    Weswegen es schnell nicht mehr damit getan ist,
    nur einen DbDataAdapter mit einem DbCommandBuilder zu verheiraten.

    Und schon für eine relativ einfache Persistenzschicht gehen schnell einige
    Mannwochen ins Land (auch wenn man ADO.NET bereits beherrscht -
    selbst bin ich seit NET 1.0 dabei).

    Was das ORM angeht:
    Da dürfte bei Microsoft die Entscheidung für das Entity Framework entschieden sein.
    Zumal Linq To SQL nur für den SQL Server (Compact) existiert -
    und somit nicht universell nutzbar ist.
    Ein Neueinsteiger sollte gleich bei 4.0 anfangen, derzeit CTP ,
    wo viele Anfangsschwächen ausgeräumt werden.

    Ich hatte deswegen NHibernate erwähnt, das ein Java Port ist und eine
    längere Entwicklungsgeschichte vorweisen kann. Und derzeit IMHO
    ausgereifter als das in 3.5 SP1 existierende Entity Framework gelten kann.

    Gruß Elmar


    Sonntag, 17. Januar 2010 10:13
    Beantworter

Alle Antworten

  • Hallo Holger

    nein, AcceptChanges persistiert nicht, sondern setzt den Änderungsstatus aller Zeilen auf unverändert,
    womit alle Änderungen verloren wären.

    Zum Aktualisieren benötigst Du wiederum den DbDataAdapter (des Providers) mit
    entsprechenden Aktualisierungsbefehlen und die DbDataAdapter.Update Methode
    Der ruft Insert-/Update/DeleteCommand entsprechend des Änderungsstatus auf
    und führt bei erfolgreicher Änderung AcceptChanges aus.

    Willst Du die SQL Befehle nicht selbst erzeugen, so solltest Du einen DbCommandBuilder
    verwenden, der die SQL Befehle für zumindest für Basistabellen erzeugen kann
    und mit dem DbDataAdapter zusammenarbeitet.

    Der wiederum benötigt den Primärschlüssel (den eine Tabelle immer haben sollte)
    und Du solltest deswegen das Schema mit MissingSchemaAction.AddWithKey erzeugen,
    siehe Hinzufügen vorhandener Einschränkungen zu einem 'DataSet' (ADO.NET)

    Mehr dazu findest in den Grundlagen zu ADO.NET

    Nur da Du ganz am Anfang stehst, solltest Du Dich eingangs fragen,
    ob die Welt noch eine weitere Persistenzschicht benötigt ;-)

    Mittlerweile hat Microsoft die Vorzüge eines O/R Mappers erkannt und bietet das
    ADO.NET Entity Framework an, das oberhalb der von ADO.NET angesiedelt ist.
    Daneben gibt es weitere O/R Mapper wie zum Beispiel das freie NHibernate
    Die bieten deutlich mehr als man selbst in kürzerer (oder auch längerer) Zeit
    ímplementieren kann.

    Gruß Elmar
    Sonntag, 17. Januar 2010 09:01
    Beantworter
  • Hallo Elmar,

    vielen Dank für deine Antwort :o)

    Genau darum geht es ja. Ich will kein SQL zum erzeugen einer Tabelle schreiben, da ich sonst für jede Datenbank die ganzen Datenbankspezifischen besonderheiten selbst hinterlegen muss. Da es nun ja schon managed Provider für diverse Datenbanken gibt, dachte ich das es mit diesen möglich ist, dieses spezifika zu umgehen,
    indem diese diese selbst hinterlegen (z.B. für SQLServer und Oracle). Dies scheint aber nicht der Fall zu sein?

    Mit den O/R Mappers gebe ich dir schon recht. Nur traue ich da Microsoft nicht wirklich. Verwende ich nun LINQ oder das Entity Framework? Welches von den beiden wird evtl. mal eingestampft und welches darf "überleben"? Schliesslich will ich ja später keinen "toten Gaul reiten" :o)

    Viele Grüße
    Holger M. Rößler
    Sonntag, 17. Januar 2010 09:14
  • Hallo Holger,

    der CommandBuilder erzeugt eben das SQL, was teilweise providerspezifisch ist.
    Wobei Du dort schon Probleme bekommst, wenn Du z. B. Identätswerte hast,
    die je nach RDBMS anders erzeugt werden (Identity, Sequence usw.)
    Weswegen es schnell nicht mehr damit getan ist,
    nur einen DbDataAdapter mit einem DbCommandBuilder zu verheiraten.

    Und schon für eine relativ einfache Persistenzschicht gehen schnell einige
    Mannwochen ins Land (auch wenn man ADO.NET bereits beherrscht -
    selbst bin ich seit NET 1.0 dabei).

    Was das ORM angeht:
    Da dürfte bei Microsoft die Entscheidung für das Entity Framework entschieden sein.
    Zumal Linq To SQL nur für den SQL Server (Compact) existiert -
    und somit nicht universell nutzbar ist.
    Ein Neueinsteiger sollte gleich bei 4.0 anfangen, derzeit CTP ,
    wo viele Anfangsschwächen ausgeräumt werden.

    Ich hatte deswegen NHibernate erwähnt, das ein Java Port ist und eine
    längere Entwicklungsgeschichte vorweisen kann. Und derzeit IMHO
    ausgereifter als das in 3.5 SP1 existierende Entity Framework gelten kann.

    Gruß Elmar


    Sonntag, 17. Januar 2010 10:13
    Beantworter
  • Vielen Dank für deine ausführlichen Antworten und deine Hilfe :o)

    Viele Grüße
    Holger M. Rößler
    Sonntag, 17. Januar 2010 10:23