DataSet-Probleme

[informatikerin86]

Hallo Leute,

ich habe ein riesen Problem, nun schon zum zweiten mal!

Mein DataSet (im Designer erstellt) hat etwa 100 Tabellen drin. Vor einer Woche habe ich dann noch eine dazu erstellt dann ist Visual Stdio 2008 abgestürzt. Danach kamen zig Fehlermeldungen. Im Ordner habe ich entdeckt das die Datei DataSet.Designer doppelt vorhanden war, deshalb die Konflikte. Wenn ich die Datei allerding lösche dann kommt der Fehler das er sie nicht finden kann. Entweder einen oder viele Fehler aber in beiden Fällen kein lauffähiges Programm...

Ich wollte nicht nachfragen da sicher der Tipp kommt das nicht über den Designer zu machen. Allerdings läuft mein projekt dieses Jahr aus, ich muss schnell eine Lösung finden.

Letzte Woche habe ich eine ältere Sicherung genommen und alle Änderungen wieder neu gemacht. Danach hat es funktioniert. Nach einer Änderung an einer Tabelle im DataSet stehe ich nun wieder vor dem Problem.

Ich könnte heulen...

Kann mir vielleicht jemand bei dem Problem helfen?

Viele Grüße

Informatikerin

Ach ja: Es taucht dann auch immer die Warnung auf das ein Fehler beim benutzerdefinierten Tool zur Verarbeitung der DataSet.xsd aufgetaucht ist.

[.NETter]

Hallo!

Alo ich kann Dir dafür keine Patentlösung nennen. Aber ich hatte einen ähnlichen "Absturz" einer Anwendung nachdem ich eine Tabelle im DataSet kopiert habe, also Strg+C und Strg+V.

nachdem ich diese Tabelle wieder gelöscht hatte war das Problem verschwunden.

Viele Grüße,

Thomas

[informatikerin86]

Daran kann es bei mir leider nicht liegen da ich das komplette DataSet neu erstellt habe...

Ein Teil des Problems ist gelöst, oder wie man es nimmt, jedenfall lösche ich die unsichtbare zweite Datei dann zeigt er keine Fehler mehr an. Wenn ich dann allerdings wieder etwas am DataSet ändere kommt der Fehler auch wieder.

[Gateway_man]

Ich habe deinen Verlauf bezüglich Datenbanknutzung schon des längeren mitverfolgt und du ewähnst ständig das du Datenbank technisch alles über den Designer von VS tätigst.

Aus eigener Erfahrung kann ich sagen das der Desginer von VS selbst in der 08 oder 10ner Version bei weitem nicht ausgereift ist und noch einige logische Fehler beinhaltet.

Deshalb würde ich dir nahelegen das du deine Connection zur Datenbank sowie deine Querrys und deine Tables komplett über den Code tätigst.

Erstens sammelst du dabei wesentlich mehr Hintergrundwissen und zweitens ist dies weitaus weniger Fehleranfällig.

PS: Nur ein gutgemeinter Rat!

[Argbeil]

Das Problem hatte ich noch nicht, allerdings klingt 100 Tabellen in einem Dataset extrem gefährlich. Wenn du das Dataset mal serialisieren willst hast du sofort extrem viel Overhead, Xml ist ein geschwätziges Protokoll. Kannst du die Tabellen nicht logisch auf mehrere Datasets verteilen? Vermutlich kommt der Xml/C# Generator mit der Menge nicht klar.

[informatikerin86]

Hallo,

ich habe mir den letzten Rat zu Herzen genommen und das DataSet aufgeteilt.

Das war ein riesen Aufwand. Eben wegen dem Designer-Zeug...

Zumindest habe ich jetzt keine Probleme mehr.

@Gateway_man: den rat hast du mir schon einmal gegeben. ich bin auch absolut der meinung das du recht hast damit den designer nicht zu benutzen. allerdings reicht mir die zeit dazu nicht aus. in 2 wochen muss das projekt fertig sein da ich das unternehmen wechsle. desweiteren haben mich die vielen Spalten davon abgehalten. Ein SQl-Befehl würde locker eine halbe Seite ausmachen. Für den Designer spricht dabei das er das selbst erledigt.

für mein nächstes projekt, das sicher kommen wird, habe ich mir fest vorgenommen den designer zu ignorieren!

Denn die meisten Probleme die ich hier gepostet habe haben etwas damit zu tun!

[Argbeil]

Dem Ratschlag den Designer generell nicht zu verwenden kann ich nicht zustimmen, generell ist das schon ein gutes Werkzeug. Wir haben hier eine mehrschichtige, komplexe Client/Server Anwendung, die Datenbank hat ca. 200 Tabellen und produktiv ca. 1TB Datenvolumen.

Solange man sich an gewisse Regeln hält funktioniert der Designer eigentlich ganz gut, das befüllen der Tabellen realisieren wir über einen eigenen SQL-Generator in Kombination mit einem DataAdapter.

Sicher kann man das auch über untypisierte Datasets lösen, die bringen aber viele Nachteile mit sich (Keine Typsicherheit, Performance Nachteile durch Boxing/Unboxing, schlechte Validierungsmöglichkeiten, keine benannten Spaltenproperties, etc...)

Man sollte generell versuchen nicht mehr als 10 Tabellen in ein Dataset zu packen. Wenn man die Datasets logisch trennt (CustomersDS, OrdersDS, ...) läuft das eigentlich ganz gut und hat eine bessere Übersicht.

Für das nächste Projekt würde ich O/R Mapper wie NHibernate oder Entity Framework in Kombination mit Views und Insert-Triggern verwenden sofern es noch kein Datenbankmodell gibt, aber die Variante mit typisierten Datasets haben sich bei uns sehr gut bewährt und funktionieren auch für komplexere Anfroderungen sehr gut (Master/Detail Forms, Paging, nachladen beim scrolling, etc.), zudem ist die Performance gut. Schneller geht es unter .net nur mit DataReadern, die machen aber auch wieder die Entwicklungsproduktivität kaputt.

[Gateway_man]

Sicher kann man das auch über untypisierte Datasets lösen, die bringen aber viele Nachteile mit sich (Keine Typsicherheit, Performance Nachteile durch Boxing/Unboxing, schlechte Validierungsmöglichkeiten, keine benannten Spaltenproperties, etc...)

Alles was du über den Designer machen kannst, ist über den Code ebenfalls Realisierbar. Nur ist der Auwand dabei etwas größer da du viele Properties die im Designer schon vordefiniert sind im Code eigenständig definieren must.

Was zum einen den großen Nachteil mit sich bringt das man schnell Gefahr läuft das man sich in seinem eigenen Code nichtmehr auskennt (was aber durch kommentare recht gut kompensiert werden kann).

Aber meines erachtens hat es eben den Vorteil, dass ich wesentlich performanter arbeiten kann als es der Designer für mich macht.

Zum beispiel kann ich größere Querrys, wo ich schon weiß das diese unter umständen längere Zeit in anspruchen nehmen können, seperat in Hintergrundprozess auslagern.

Somit ist gewährleistet das ich mit dem Programm flüssig weiterarbeiten kann.

Was mir bei dem Designer immer öffters passiert und für mich unbeschreiblich ist, ist folgendes Phänomen:

Ich Debugge eine Anwendung und als ich diese wieder schließe wird mir ein Fehler im Designer angezeigt und ich kann nichtmehr auf mein Form zugreifen.

Dann kommt das kuriose. Um den "Fehler" zu beheben, gehe ich in den Designercode zu der Stelle, welche Blau unterstrichen ist, mach ein paar Linefeeds um dann im anschluss wieder solange Return zu drücken bis der Code wieder wie zuanfangs dasteht.

Nur mit dem unterschied das der Code jetzt nichtmehr von VS bemängelt wird.

[Argbeil]

Klar kann man alles von Hand machen, der Designer generiert ja auch nur Code über den Schema Generator, das der Aufwand "etwas" größer ist finde ich untertrieben. Mit performanter arbeiten meinst du dann vermutlich die Runtime-Performance? Wenn wir über das reine, erzeugte typisierte Dataset bzw. die DataTables reden glaube ich nicht das du messbare Performance Verbesserungen sehen wirst.

Methoden für asynchrones laden stellen komischerweise weder der TableAdapter noch ein DataAdapter zur Verfügung, ist aber relativ leicht zu implementieren, da für lohnt selbstschreiben auch nicht.

Der erzeugte TableAdapter ist eine partial class. Du kannst dir z.b. eine AsyncGet Methode hinzufügen, stellst den GetData() Job in einen ThreadPool und feuerst beim beenden ein Event mit der befüllten Table als EventArgs, ist ein 2 Zeiler. Die partielle Klasse bleibt auch bei Änderungen im Designer erhalten. Könnte z.B. so aussehen:

    public partial class AddressTableAdapter {


        public void AsyncGet()

        {

            ThreadPool.QueueUserWorkItem(new WaitCallback(this.ThreadWorker));

        }


        public void ThreadWorker(object state)

        {

            AdventureWorksDataSet.AddressDataTable table = this.GetData();

            // Event auslösen mit Table als EventArgs...

        }

    }

Den beschriebenen Fehler hab ich noch nie geseheh, klingt aber nach einem Problem mit dem Background-Compiler, bei mir (VS2008SP1) tritt das nicht auf. Reden wir von dem Forms Designer oder vom Dataset Designer? Durch die Returns wird vermutlich der Schema-Generator neu gestartet, dann müsste aber auch ein Rebuild helfen, möglicherweise ist auch beim Dataset nicht der MSDataSetGenerator als Build-Tool eingestellt.

[Gateway_man]

Den beschriebenen Fehler hab ich noch nie geseheh, klingt aber nach einem Problem mit dem Background-Compiler, bei mir (VS2008SP1) tritt das nicht auf. Reden wir von dem Forms Designer oder vom Dataset Designer? Durch die Returns wird vermutlich der Schema-Generator neu gestartet, dann müsste aber auch ein Rebuild helfen, möglicherweise ist auch beim Dataset nicht der MSDataSetGenerator als Build-Tool eingestellt.

Die Rede ist vom Form Designer in VS 08 SP1.

Ich kann nicht Rebuilden, dann weißt er ja eben auf den "ominösen Fehler" hin.

Lg

Gateway

[Argbeil]

Ah so. Den Forms-Designer verwende ich nicht, der Fehler ist mir auch nicht bekannt.