Laden...
Avatar #avatar-2389.jpg
Benutzerbeschreibung
Wirtschaftsinformatik/Informationswirtschaft am KIT, Karlsruhe

Forenbeiträge von Razer Ingesamt 84 Beiträge

29.11.2008 - 17:36 Uhr

Beispiel:



// DataTable mit Daten
DataTable dt;

// TextBox Control
TextBox txtName;

// BindingSource =  Brücke zwischen Datencontainer und Controls
BindingSource bnd;

// Bindung einer TextBox an den aktuellen Datensatz der BindingSource
txtName.DataBinding.Add("Text", bnd.Current, "Name");

// 1. Parameter: Eigenschaft des Controls, die gebunden werden soll
// 2. ~ : Datenquelle
// 3.: Eigenschaft der Datenquelle, welche die die Daten liefert


29.11.2008 - 17:30 Uhr

Im folgenden ein nützlicher Link zum Thema Enity Framework & n-Layers.
Eines des wenigen Beispiele von MS, in denen eine Architektur in ihrer Gesamtheit gesehen wird. Die Code-Samples in der MSDN sind ja nicht selten etwas.. nennen wir es naiv 😉

"The Entity Framework In Layered Architectures" (!),
http://msdn.microsoft.com/en-us/magazine/cc700340.aspx

Meiner Meinung nach ein exzellenter Artikel. Zusammen mit dem Model-Viewer-Pattern (wird ebenfalls erklärt) ergibt sich wie ich finde eine sehr saubere Architektur.

Bei dem ganzen EF-Bashing das sich derzeit in vielen Foren findet wird oft übersehen, dass die Probleme mit dem _ObjectContext _hauptsächlich in N-Tier-Anwendungen zu Schwierigkeiten führt.

Für N-Layer-Anwendungen bietet das EF auch in seiner jetzigen Form schon sehr viele Vorteile - und wer einmal eine Datanbank-Abfrage mit LINQ geschrieben hat, wird nur widerwillig wieder SQL-Strings zusammenbauen wollen.

28.11.2008 - 19:57 Uhr

verwendetes Datenbanksystem: MSSQL 2005 Compact

Hallo Community,

ich habe mal wieder eine Frage:
Ich arbeiter derzeit an einem kleinen Tool zur Zeiterfassung. Ich bin ganz stolz, das ich es (fast) Datenbank unabhängig geschaft habe mit Linq-to-SQL.
Allerdings wirft das auch meine Frage auf, was passiert wenn ich Änderungen an der Datenbank vornehme. Sprich neue Tabelle, neue Spalte usw...
Wenn ich das Tool jetzt so raus gebe und dann irgend welche Änderungen am Schema machen muss? Gibt es da irgend welche "Best Practice"?

Vielen Danke!
Grüße
HyperteX

Nach dem Deployment sollte sich der Aufbau der Datenbankanwendung eigentlich gar nicht mehr ändern. Wenn du das DB Schema nachträglich änderst, wirst du in fast allen Fällen eine Menge Ärger mit nicht mehr funktionierenden Abfragen und ähnlichem bekommen.

Im Übrigen ist LINQ-to-SQL ganz und gar nicht Db-unabhängig, im Gegenteil:
Außer die SQL Server 2005/2008 und in Teilen auch die Compact Edition von MS werden keinerlei DBMS unterstützt.

31.07.2008 - 22:41 Uhr

Hmm also es ist ja schon angerissen worden:

In den DataSets steckt wohl einiges an Arbeits seitens MS, und in einem Punkt kann man sich wohl sicher sein: da sind keine Frickler am Werk.

Von der Performance her kann ich bei ihnen keine Schwachstelle erkennen, und die große Menge an generiertem Code führen ja nicht zwangsläufig zu einem komplexen Zugriff.
Im Gegenteil, wenn ich eine Zeile oder eine Zelle einer DataTable in einem DataSet auslese, dann fällt bei reinsteppen in den Code auf, dass es sich logischerwerise fast nur um Typüberorüfungen etc. handelt, völlig transparent.

Was imho allerdings tatsächlich kritisch zu sehen ist, ist die Verquickung von DB-Verbindung und Datencache, den einen solchen stellt das DS ja eigentlich dar.

Die TableAdapter koppeln diesne Cache nun an die Verbindung, und bei späteren Änderungen u.ä. wirds tatsächlich richtig hässlich, es entsteht ein "Matsch" aus Komponenten / Schichten derin den allermeisten Fällen tatsächlich nicht zusammengehört.
Diese Funktion die den Connection String dann in der App.Config hinterlegt etc - wer hat denn das verbrochen?

20.07.2008 - 23:20 Uhr

Happy Birthday und ein Dankeschön ans Team 🙂

16.07.2008 - 23:18 Uhr

Naja, also ganz so easy ist es meiner Meinung nach nun leider nicht..

Sortieren klappt mit den meisten der diversen Listen, aber wehe man versucht einen FilterString dranzuhängen, dass kann man gleich wieder vergessen. Und simple "Feld A = X" Filter-Items oder ähnliches - das könnte ich auch fast gleich mit Linq vorher rausfiltern.

Prinzipiell hätte ich ja nichts dagegen, alle Filtereien mit LinQ zu machen, aber richtig variable StringFilter bekommt man - meines Wissens nach - selbst mit Dynamic-Linq auch nicht gebacken.

Da ich einige FilterStrings mit dem FilterControl von DevExpress zusammenbauen lasse, sind diese leider nicht immer nach dem Schema ABC aufgebaut.

d.h. also ganz konkret und platt gesagt:
wie hänge ich eine List<T> an eine BindingSource, sodass ich a.) ohne weiteres Sortieren kann, und b.) bliebig komplexe Filter-Bedingungen als String anwenden kann?

Also ich bin sicher kein Profi, aber ich suche jetzt schon seit einigen Tagen - und eine vernünftige Lösung ist nicht in Sicht.

14.07.2008 - 19:55 Uhr

Ja, die beiden Beiträge kenne ich, bin bei meiner Suche ebenfalls auf sie gestoßen, und spiele gerade etwas damit herum, wobei ich den zweiten damals zugegebenermassen dann irgendwie nicht wirklich gelesen hatte, es scheint wohl nur bzgl Linq on SQL diese Verbesserung gegeben zu haben.
Bzgl. der BindingViewList:
Trotzdem ist es doch bemerkenswert, dass es eigentlich nur dem Bemühen dieses einzelnen Studenten zu verdanken ist, dass es diese Möglichkeit gibt. Eine Eigenimplementierung ist doch recht aufwending, und für mich nicht wirklich realisierbar.
Sortieren und filtern habe ich zwischenzeitlich mit DynamicLinQ hinbekommen.
Eigentlich komisch, das MS die Dynamics-Klassen standardmäßig mit in die Klassenbibliothek reinnimmt.

14.07.2008 - 10:18 Uhr

Ja, natürlich hast du Recht, die BindingSource an sich wird nicht eingeschränkt, es ist die Form der zugrunde liegenden Daten, die diese Einschränkung mit sich bringt, das habe flapsig ausgedrückt; die BindingSource greift ja ledeglich auf die dort vorhandenen Funktionalitäten zurück.

Nichtsdestotrotz denke ich, dass es doch irgendwo wiedersprüchlich ist, auf der einen Seite tolle neue Möglichkeiten durch LinQ zu haben, auf der anderen Seite in der Praxis daraus aber keinen deutlichen Gewinn erzielen zu können, weil Komponenten z.B. zur Visualisierung bzw. Bindung nicht mehr die Funktionalität zur Verfügung stellen können, wie das der Fall wäre, wenn man einfach ein DataTable aus einem klassischem Select Statement dranhängen würde.

Das mag zum Teil in der Natur der Sache liegen, für mich als Entwickler bedeutet es zunächst einmal schlicht mehr Aufwand (-> Warum muss ich jetzt zu DynamicLINQ greifen, um einfach mein DataGridView zu sortieren?). Vllt. ist die Lage für Vollzeit-Entwickler allerdings etwas anderst.

11.07.2008 - 17:06 Uhr

Naja es gibt durchaus eine Menge an Problemen, wenn man kein DataTable ans DGV hängt; DataGridViews und BindingSources werden quasi in ihrer Funktionalität verkrüppelt X(:

  • DGV kann nicht mehr automatisch sortiert werden
  • BindingSource kann keine FilterStrings mehr anwenden.

Am Ende habe ich dann zwar Abfragemöglichkeiten mit LinQ, aber auf was fängt man mit einem DataGridView an, dass nicht mehr sortieren kann, bzw. einer BindingSource die keine simplen RowFilter mehr packt.

Habe in der Zwischenzeit eine erweiterte Implementierung der CopyToDataTable Methode gefunden, allerdings ist die viel zu lahm, als dass man Sie bei mehrern tausend Zeilen noch sinvol einsetzen könnte 🙁

07.07.2008 - 17:20 Uhr

@herbivore:
d.h. grob gesagt: Der Aufruf einer Manager-Methode (z.B. Customer.AddCustomer()) wird innerhalb einer Form in einen try/catch-Block eingebettet, der dann eine mögliche AccessDenied-Exception behandelt.

@winSharp93
Ja, das wäre aus theoretischer Sicht auch eine Möglichkeit.
Zum einen Verwende ich jedoch Sqlite, bei dem dieses Rechte-Management sowieso nicht wirklich vorhanden ist, zum Anderen sind die Beschränkungen, die man in den üblichen DBMS i.d.R. definieren kann meines Wissens nach nicht sehr differenziert und im Vergleich zu einer Software-Internen Lösung eher unflexibel.

06.07.2008 - 13:55 Uhr

Ja, da hast du schon durchaus Recht. 🤔
Ich hatte mich da irgendwie so auf die DataTables eingeschossen, weil es ohne LinQ ja irgendwie immer üblich war, Abfrage in Form eines DataTables zurückzugeben, falls man die Daten in einem Cache vorhielt, und anschließend in irgendeiner Form anzeigen wollte.. =)

06.07.2008 - 13:52 Uhr

Hallo,

Ich habe wieder mal eine Designfrage, die Ausgangssituation ist die folgende:

Es können Benutzerkonten mit jeweils konfigurierbaren Privilegien erstellt werden. Die Information, ob der angemeldete Benutzer für eine Vorgang über die nötige Berechtigung verfügt, wird aus einer DB gelesen.
Für den Fall, das diese Berechtigung nicht gegen ist, muss natürlich eine ensprechende Vorkehrung getroffen wrden, bestehend aus

a.) Info über die Zugriffsverletzung an den Benutzer
b.) Verhindern / Rückgängig machen der Änderung

Die Frage ist nun:
Auf welcher Ebene realisiert man das?
Die Daten liegen im Übrigen in einem DataSet
Ich schwanke zwischen den folgenden Möglichkeiten:

a.) statische "Protector"-Klasse, die die RowChanged-Events etc. abonniert, und Änderungen bei fehlender Berechtigung rückgänig macht / verwirft + MessageBox

->Vorteil: Man muss nicht bei jedem Aufruf einer Manager-Klasse extra eine Exception bzgl. der Rechteverwaltung werfen, alles wird im Hintergrund von der "Protector"-Klasse überwacht.

-> Nachteil: Wie bekommt der Dialog mit, dass seine aufgrund fehlender Rechte Aktion gecancelt wurde?

b.) Jeder Aufruf einer Bearbeitungsfunktion in einem Dialog wird in eine try/catch-Packung gesteckt. Die Manager-Klasse überprüft, ob die Rechte vorhanden sind, wenn nicht wirft sie eine spezielle Exception, auf die der Dialog reagieren kann.

Grundsätzlich scheint mir a.) irgendwie eleganter vorzukommen, da die Überwachung praktisch im Hintergund automatisch vorgenommen wird, und jeder Veränderung der Daten mit Sicherheit erfasst wird...

03.07.2008 - 23:20 Uhr

Sorry für die späte Rückmeldung, danke für deine Tipps

hmm ja, mittlerweile hab ichs tatsächlich so ähnlich hinbekommen, man verzettelt sich da eben leicht in der Menge von Typen, Listen, Array etc..

Die Webcasts von MS finde ich prinzipiell auch gut, nur leider geraten sie nicht selten seehr langatmig, und man muss sich idr. erstmal durch die nicht gerade übersichtliche Auflistung kramen, und dann hoffen dass die Thematik halbwegs getroffen wird - oft kommt man (leider) mit einer halben Stunde googlen oder einem Tutorial schneller weiter..

03.07.2008 - 23:14 Uhr

Wenn in deinem Fall das Arbeiten mit Caching-Daten kein Problem darstellt, kanst du die Daten aus der DB auch in ein (bevorzugt typisiertes) DataSet laden, via LINQ to Objects bearbeiten und anschließend wieder zurückspielen.

07.06.2008 - 12:42 Uhr

Hallo,

ich beschäftige mich derzeit etwas mit LINQ 🙂 .. Prinzipiell eine geniale Sache, nur scheint es an manchen Stellen ein paar hinderliche **Beschränkungen **zu geben.

-> Normalerweise kann man das Ergebnis einer Abfrage ja z.B. via

CopyToDataTable()

oder

 AsDataView()

bequem und handlich zurückliefern.

Enthält die Abfrage jedoch Joins, oder projeziert die Daten auf irgendeine Art, dann sind diese zwei Methoden nicht mehr verfügbar, dass bestätigt auch die MSDN.

Es muss aber doch eine Möglichkeit geben, auch ein solches Ergebnis in die Form eine DataTables oder DataVews zu bringen, um damit weiterarbeiten zu können.

Die Aussicht, die Abfrage Zeile für Zeile durchzuiterieren, und dann daraus ein DataTable zu zimmern, finde ich nicht sehr berauschend 🤔

Hatte hier vllt. schonmal jemand ein ähnliches Problem?

Gruß,
Razer

04.04.2008 - 17:49 Uhr

DataGridViewTest.DataSource = varBsp.CopyToDataTable(), wär auch vorstellbar

Gruß,
Razer

31.03.2008 - 14:38 Uhr

LINQ kannst Du gleich vergessen, das funktioniert nicht mit MySQL.

Deshalb auch der Vorschlag von meiner Seite, LINQ auf ein entsprechendes Abbild der Datenbank in Form eines DataSet anzuwenden.

Die richtige Methode gibt es nicht, nur eine geeignete für einen bestimmten Anwendungsfall.

Wobei sich die Anwendungsfälle aber im Wesentlichen z.B. auf die Kriterien Multiuserfähigkeit und Zielplattform (MySQL etc) reduzieren lassen.
Ich denke schon, dass es Verfahren gibt, die im Großteil der Fälle bessere Lösungen unter den üblichen Aspekten bieten.

Im Endeffekt werden nunmal Daten abgerufen und Daten gespeichert. Die eingangs erwähnten Umstände sind zu berücksichtigen.
Was für Daten in diesem an sich generischen Vorgang verarbeitet werden, spielt aber aus technischer Sicht im Normallfall doch gar keine Rolle.
Deshalb gilt es meiner Ansicht nach, für dieses allgemeine Verfahren eine möglichst gute Lösung zu finden.

Ich bemerke zum Anderen allerdings gerade auch, dass mit solcherlei Diskussionen dem Thread-Eröffner wohl eher weniger geholfen ist...

Gruß,
Razer

30.03.2008 - 14:44 Uhr

Also:

Zunächst ist es natürlich sinnvoll zu wissen, wie den mit den Daten in den anderen Bereichen umgegangen wird.

Ich würde dir zu folgendem Aufbau raten:

**Typisiertes DataSet **(= generisches DataSet mit Schema-Informationen über den Aufbau der Datenbank):

-> Während des Betriebs wird via LINQ nur auf diese In-Memory-Abbildung der wirklichen Datenbank zugegriffen. Mit LINQ steht dafür eine sehr mächtige, SQL-ähnliche Syntax zur Verfügung.

-> Sobald die Änderungen, die in der In-Memory-DB (in Form des DataSets) gemacht wurden, auch in der tatsächlichen DB übernommen werden sollen, genügt es die entsprechenden Methoden des generierten typisierten DataSets zu verwenden.
Weil bei der Generierung des DataSets der exakte Aubau (=Schema) von der wirkllichen DB übernommen wurde, weis das DB, wie die entsprechenden INSERT, UPDATE und/oder DELETE-Befehler auszusehen haben, und hat sie bereits intern hinterlegt.
Es genügt dann, auf deinen Fall bezogen, z.B. DataSetMessdaten.Table1.Update() aufzurufen, und die in im DataSet gemachten Änderungen werden auch für die richtige DB übernommen.

Vorteile:

-> Typsicherheit:
Casting/Konvertierungs-Scherereien können oft schon durch die Intellisense-Überwachung aufgedeckt werden.

++-> Intellisense-Unterstützung: ++
Während des Programmierens kann man sich via Intellisense durch die Klassen "hangeln", "No Such Table"-Fehler werden damit unwahrscheinlich.

-> Äußerst effizient bzgl. Coding-Aufwand
Du sparst einen Großteil an Codezeilen der leidigen Erstellung von SQL-Befehlen.
Kein Rumhantieren mit Strings etc. - alles kann **äußerst ** bequem via LINQ erledigt werden.
Bsp:
Alle Messdaten aus Projekt "X" holen!
->

from p in DataSetMessdaten.ProjektTable
where p.ProjektName == "X"
orderby p.ProjektDatum
select p;

++-> Performant: ++
LINQ on DataSet ist sowieso sauschnell, das anschließende Update auf die wirkliche DB kann mit Transaktionen sehr elegant beschleunigt werden.

-> Unabhängigkeit von LINQ-To-SQL-Providern:
LINQ on DataSet klappt immer, während LINQ-To-SQL bisher nur für einige wenige (hauptsächlich kommerzielle) Systeme wie MS SQL oder Oracle verfübar ist.
D.h. einzige Voraussetzung ist ein MySQL-.NET Provider, aber ich bin mir sicher dass es da einige Möglichkeiten gibt.

.. und noch eine ganze Reihe weiterer Vorteile, diese sind mir jetzt so in den Kopf gekommen.

Gruß,
Razer

30.03.2008 - 11:07 Uhr

Hi Muffin,

ich werde dir, da ich aktuell auch viel mit DBSen zu tun habe nacher auch noch einen Vorschlag machen, bin nur im Moment gezwungen etwas mit der Zeit zu haushalten 😉
Kommt deshalb im Laufe des Mittags..

Gruß,
Razer

16.03.2008 - 19:38 Uhr

Hi HuiBuh,

danke, funktioniert einwandfrei.
Wenn man sich einmal auf einen Lösungsweg eingeschossen hat (Binding), übersieht man leicht eine solche, alternative Lösung 😉

Gruß,
Razer

16.03.2008 - 17:58 Uhr

Hallo

weis jemand ob die Möglichkeit besteht, eine Text-Property (z.B. eines Labels) direkt an eine (aktuell selektierte) Zelle eine DataGridViews zu binden? Ich bekomme er derzeit einfach nicht gebacken..

Mein Ansatz war/ist der folgende:

lblCustomerID.DataBindings.Add("Text", dgvCustomers.SelectedRows[0], "CustomerID");

Eine Exception wird nicht geworfen, es wird schlicht kein Wert zugewiesen.

Ich bin für jeden Tipp dankbar 🙂

14.02.2008 - 21:37 Uhr

Grafik im Anhang runterladen, in eine PictureBox packen, die Property MaximumSize in X-Richtung auf 2 ändern, sich freuen 🙂

Gruß,
Razer

13.02.2008 - 21:45 Uhr

Grundsätzlich kann man 2 verschiedene Sprachen nicht einfach mischen, schon gar nicht wenn es sich bei der einen um eine JIT-, und bei der anderen um eine (idr.) native Sprache handelt.

Du könntest aber eine COM-DLL, die in C++ entwickelt wurde, in dein C#-Projekt einbauen.

Was hast du den Besonderes vor, das sich in C# nicht implementieren lässt?

Gruß,
Razer

13.02.2008 - 21:39 Uhr

Es sind XML-Files für Einstellungen und SQL-Code (ja, ich weis 😉 ) vorhanden..

Gruß,
Razer

13.02.2008 - 21:37 Uhr

Danke ,

bereits der erste Teil der Serie ist, im Gegensatz zu einigen MS-Webcasts, sehr informativ. Wunderpille PWA 😉

Gruß,
Razer

13.02.2008 - 21:07 Uhr

@Rainbird

Ein Nachteil besteht darin, dass ich bei statischen Geschäftsklassen der Zugriff auf z.B. XML-Daten unsauber wird.
Eine zentrale SQL-Data-Klasse ist kein Problem, es gibt sowieso nur eine DB.

Allerdings sind verschiedene XML-Files für verschiedne Zwecke vorhanden. Macht man die Klassen für den XML-Zugriff nun auch statisch, was im Falle von statischen Geschäftsklassen eigentlich die einzige Lösung ist, dann wars das mit "eine XMLManager-Instanz pro XML-File".
Oder eben jedesmal den Dateipfad als Paramater übergeben.

Aber ich weis nicht.. 🤔

Gruß,
Razer

11.02.2008 - 20:28 Uhr

@Rainbird:

Ok, dann passt das ja alles soweit 👍

Noch eine Frage bzgl. der Trennung:

-> SQLCommands inkl. den Parametern...
**
a.) **...im Business-Layer basteln und dann fertig dem Daten-Layer übergeben

oder

**b.) **...erst im Daten-Layer basteln: wie ganz oben von mir gepostet eine Methode im SQL-Layer zur Verfügung stellen, die einen CommandText und 2 ArrayListen für Parameter und Parameterwerte zur Verfügung stellt

Zu was würdest du/ihr tendieren?

Gruß,
Razer

11.02.2008 - 15:59 Uhr

Danke für die Antworten,

@norman_timo:

Singletons.. habe ich noch nie wirklich benutzt, und ich teile den Verdacht von JuyJuka und herbivore, dass Singletons desöfteren als Alheilmittel für einen globalen aber dennoch "eleganten" Zugriff aufgefasst werden.

Das für ein so doch eher "klassisches" 3-Layer-Design Singletons nötig sind, kann ich mir nicht wirklich vorstellen.

@JuyJuka:

Das stimmt, die Business-Klassen haben absolut keine Zustände. Dein Vorschlag läuft, wie man auch aus deinen bisherigen Posts erkennen kann, wohl in Richtung eines O/R-Mappers. Leider bin ich momentan gezwungen, auf Basis des Frameworks 2.0 zu programmieren, d.h. LINQ fällt schon mal flach.
Die Einbindung eines externen Mappers will ich vermeiden, folglich sind Bordmittel angesagt.

Wie du auch schon ganz richtig beobachtet hast, sympathisiere ich eher mit den Konzepten von Rainbird u.a., der ein ähnliches Layer-Projekt ja schonmal als Beispiel-Code gepostet hat.
Allerdings wird da auch gleich mit Controllern etc. um sich geworfen, was für meine Zwecke (hoffe ich 😉 ) einfach oversized ist.

Gruß,
Razer

11.02.2008 - 14:31 Uhr

Hallo,

ich entwickle derzeit eine ADO.NET-Anwendung unter C#. Die Verteilung der Zuständigkeiten 3-Layer-Design ist mir soweit klar, allerdings bin ich mir bezüglich der Implementierung nicht sicher:

Vorhandenes Modell:

Data Access Layer: z.B.

public DataTable GetData(String CommandText, ArrayList Parameters, ArrayList ParameterValues)

Business Layer: z.B.

public DataTable GetCustomerOrders(String CustomerID)

Presentation Layer: z.B. (Anweisung)

BindingSourceX.DataSource = GetCustomerOrders("DonaldTrump")

-> Frage:

GetCustomerOrders() ist eine Methode der Klasse "CustomerManager.cs" - Wie ist diese (an sich ja recht saubere) Klasse nun zu nutzen?

1.) Erzeugt jeder Use Case, Dialog etc. seinen eigene Instanz von CustomerManager?

2.) Oder baut man die CustomerManager-Klasse statisch auf, d.h. alle Use Cases greifen global darauf zu?

  1. scheint mir nicht elegant, weil die "CustomerManager"-Instanzen wiederum Instanzen einer XML-DataAcess-Klasse erzeugt - d.h. am Ende hab ich einen Haufen unnötiger Objekte für den XML-Zugriff. Statische XML-Klassen finde ich eher weniger geschickt, da ich nicht jedesmal noch den Pfad der XML-Datei als Parameter angeben möchte, sondern nur einmal durch den Konstruktor

  2. scheint mir auch nicht elegant, bis auf z.B. Dialoge oder die XML-Access Klasse währe die Anwendung dann statisch aufgebaut, wohl eher nicht im Sinne einer modern strukturierten, objektorientierten Sprache.

Kann mir jemand einen Anstoß geben, auf welche Richtung man sich einschießen sollte, bzw. welcher goldene Vorschlag Nr. 3 eine Lösung bringt ? 😉

Schon im Voraus vielen Dank für die Bemühungen, tolles Forum 🙂

Gruß,
Razer

17.09.2007 - 19:56 Uhr

also doch..
...ich hatte das auch schon in Betracht gezogen, den das Platten-Rödeln ist ja ein gutes Indiz dafür.
Nur stand dann in der SQLite-Doku, dass er für ein Update-Command automatisch eine übergreifende Transaction benutzt - vermutlich hab ich da aber was falsch verstanden -

Vielen Dank für den Tipp 🙂

17.09.2007 - 18:38 Uhr

verwendetes Datenbanksystem: SQLite

Hallo,

wie schon im Titel steht - > 50000 Datensätze aus einer CSV Datei sollen in eine SQLite-DB importiert werden...

Bisher mache ich das über die DataAdapter.Update()-Funktion: Ich schreibe alle Datensätze aus dem CSV in ein DataSet, und Update dann eben meine SQLite-DB mit diesem DataSet. Das Problem dabei ist, das SQLite beim Abgleichen der Datens scheinbar keinerlei eigene Schreibcaches oder dergleichen nutzt -> HD rödelt sich zu Tode, während die CPU-Auslastung nur minimal ist.

--> Frage: Gibt es irgendeine andere Methode, die Daten halbwegs flott in die DB zu bekommen? Die SQLite-CMD und diverse OCDB-Verianten kommen auch nicht in Frage, schließlich soll es ja eine saubere ADO.NET Lösung bleiben...

Vielen Dank schonmal, bin für jeden Tipp dankbar 🙂

30.08.2007 - 20:50 Uhr

Jop, alles was irgendwie vom normalen Layout abweicht, oder was irgendetwas automatisch einstellt, ist beim DataGridView leider eine potenzielle Performancebremse..

30.08.2007 - 19:41 Uhr

Eine konkrete Lösung kann ich dir leider noch nicht bieten, allerdings ist dieser Verhalten auch bei vielen Datensätzen keineswegs normal.

Ich habe hier gerade ein Projekt , indem der Benutzer verschiedene Ansichten wählen kann, auch gelöst durch Ausblenden verschiedener Spalten.
Habs gerade mal getestet - mit rund 3000 Datensätzen (zeilen) tritt bei mir praktisch keine Verzögerung beim Ausblenden auf.

Hast du eventuell irgendwelche Column/Row/Cell-Styles aktiviert, oder arbeitest du mit vielen Comboboxen oder farbig markierten Zellen im DGV?
Diese können die allgemeine Performance des Grids ganz schön herunterziehen..