Allgemeine Vorgehensweise

verwendetes Datenbanksystem: <SQL Server 2005>

Hallo,

Ich habe mir in der Vergangenheit öfters eine Anwendungen geschrieben die auf Datenbanken zugreifen. Dabei habe ich die Komponenten von .Net verwendet und mir alles sozusagen zusammengeklickt.

Nun muss ich aber dynamisch auf eine Datenbank zu greifen, die Daten ändern und wieder in die Datenbank schreiben können.

Dies Ging immer wunderbar mit dem DataGridView und den Datenquellen die ich mir "STARR" zusammengeklickt habe.

Nun ist meine Frage:

Wie gehe ich vor wenn ich Daten über einen SQL Connection und einem SQL Select Befehl aus einer Datenbank auslesen möchte, und diese dann in einem DataGridView anzeigen möchte.
Der Select Befehl kann sich wärend des Programms genauso ändern wie auch meine Datenbank.

Den Befehl wie auch die SQL Connection kann ich mir ohne Probleme erstellen.

Aber wie kann ich diese sich laufend ändernden Daten in meinem DataGridView anzeigen lassen.

Und wie gehe ich vor wenn ich diese Daten über das DataGridview ändern, löschen öder ergänzen möchte?

Gruß

Also das mit dem editieren über das Datagrid selber kann ich dir jetzt ausm kopf auch net sagen, aber um die ständig wechselnden Daten azuzeigen gibts sicher ne Refresh- oder Reloadfunktion.

Das Problem fängt schon früher an.

Ich muss ja dem DataGrid erst mal sagen welche Daten er anzeigen soll.
Hierfür muss ich irgendwelche Adapter verwenden und Datasets und weis der Teufel.
Wenn ich das mit dem VS gemacht habe dann wurden auch immer die Daten angezeigt und ich konnte diese Bearbeiten und speichern.

Nun möchte ich aber alle Zwischenschritte die VS macht, um dies zu erreichen, selbst machen können, um auf den Select Befehl und die Verbindungszeichenfolge einfluss zu haben und somit auch auf die anzuzeigenden Daten.

So wie ich dich versteh scheiterst du also schon beim anzeigen.

1. Datagrid von Toolbox auf form ziehen

 DataGrid.DataSource = DBDataSet.Tabelle.DefaultView;

dann sollten dir die Inhalte angezeigt werden.

Dann kannst du so wie ich vermute auch im Grid rum editieren jedoch werden diese Änderungen erst wenn du danach einen Update oder Insert befehl machst wirklicch in der DB gespeichert.

naja, das kommt alles auf die dimensionen an. wenn es nur so ne kleine bastelei nebenbei sein soll, dann kannst du sicherlich sql-abfragen in deinen quellcode einbauen und die kannst du ja problemlos dynamisch zusammenbasteln.

wenn es professioneller werden soll, dann auf alle fälle stored procedures, aber wenn sich deine abfragen ändern dann musst du hald mehrere prozeduren schreiben.

wenn du nur mit einem datagrid arbeiten möchtest, dann kannst du auch problemlos das datagrid mittels datasource aneinander binden und das dataview speziell kannst du ja filtern. das heisst, du kannst daten aus und einblenden.

generell erzeugst du ein neuen connection und ein command objekt, dann gibst du dem command die connection und einen commandtext mit (im einfachsten falle zb "SELECT * FROM tbl") und startest das command, je nach zu erwartendem rückgabetyp mit executereader, executescalar und so weiter.

etwas mehr infos wären vielleicht nicht übel, so kann man hald nur grob anschneiden.

@toxick:
Was haben stored Procs mit Professionell zu tun?

Diese aussage war mal vor jahren OK, hat sich aber schon lange geändert.
Lediglich DB-Admins, die sich nicht überflüssig machen wo´llen behaupten dies noch.

hmm...naja, ich bin auf alle fälle kein db admin. ich frag mich nur welche alternative ich habe wenn ich keine stored procedures verwende?

das würd mich jetzt aber interessieren!

gruß
toxick

Normale parametrisierte Queries!

nicht wirklich oder?! naja, ich kann mich ja auch irren aber wenn ich bedenke dass die prozeduren vorkompiliert auf dem server warten und mir ratz fatz unmengen von daten liefern...und ich mir änderungen am quellcode sparen kann...noch dazu brauche ich die datenbank ja sowieso, warum dann nicht sauber trennen!?

ich dachte jetzt kommt ein neues feature aus dem .net 5.0 BETA dass meine daten anhand meinen gedanken zusammen stellt und nebenbei ekg genau meinen puls misst und mir ne tasse kaffee klar macht, aber abfragen in den quellcode packen?! nene, dafür hab ich zuviele bücher gelesen 🙂.

aber jeder solls machen wir er will. ich würde mich nicht wohl fühlen wenn ich das so machen würde, und ob ich die abfragen jetzt in den code oder in den server packe, schreiben muss ich die sowieso und schneller sind die abfragen sicherlich im server.

gruß
toxick

Hallo toxick,

Heutzutage macht sich das nicht mehr bemerkbar; Im gegenteil empfinde ich Stored Procedures sogar als eine unnoeitge weitere Baustelle.

Aber wie du schon sagtest, jeder wie er will 🙂

Gruss
purestrain

Das ist eben ein ziemlich weit verbreiteter Irrtum, das Stored Procs schneller sind.

Diese und die "Saubere Trennung" wird immer von DB-Admins ins Feld geführt,
hat aber nichts mit vernünftiger Architektur zu tun.

1.
Bei einer parametrisierten Query wird der Ausführungsplan auch nach dem ersten
ausführen vom Server gespeichert, es ergibt sich also kein geschwindigkeitsvorteil.

2.
Was hat Businesslogic in der Datenbank zu suchen?
Das hat mehrere nachteile, wie Portierbarkeit auf andere Systeme und
auch die Scalierbarkeit ist so nicht wirklich gegeben.

3.
Willst Du immer alle Server updaten, wenn deine Logik sich ändert?

Es gibt noch so viele andere gründe warum das heute nicht mehr gemacht
werden sollte, aber bei deiner Einstellung ist es sinnlos da jetzt weiter zu reden.

Kann da FZelle nur beipflichten.

Der wirkliche Sinn von Stored Procs besteht darin, dass wenn mehrere (!) Anwendungen auf die gleiche DB zugreifen, die BL zentralisiert werden kann (was ohne Zweifel Vorteile hat). Das kann man aber auch anders erreichen, z.B. mit einer gemeinsamen Zugriffskomponente. Erst wenn das nicht möglich ist (z.B. bei einer Alt-Anwendung oder unterschiedlichen Plattformen), sollte man SPs ins Auge fassen.

Hallo

Also da ich nun eure Antworten mit meinen eigenen Bemühungen ergänzt habe, habe ich mein Problem gelöst.

Danke an alle die geantwortet haben

na ok. vielleicht sollte ich mich doch mal mit den parametrisierten abfragen befassen, bisher gings bei mir nicht anders weil ich einen sql-server im netzwerk hab auf den alle zugreifen.

noch dazu sehe ich mir eigentlich eher als anfänger und mein professor spezial guru mcde mslmaa abcde meinte dass es so zu machen ist.

aber was solls, hauptsache es funktioniert 🙂.

bis auf die plattorm beschränkung sehe ich so jetzt keine so gewaltigen nach-/vorteile dass ich mich ärgern müsste weil ich es anders gemacht habe! aber das portieren auf andere systeme kommt eh nur dann in frage wenn ein anderes system als windows mal mehr als 10 rechner weilweit laufen hat und unsere kunden sind schon froh wenn windows läuft. da gabs noch nie ne anfrage für ein anderes system.

jetzt habt ihr mich aber neugierig gemacht. hat hier jemand nen netten link wo man sich mal ein kleines code-snippet in nem vernünftigen bsp ansehen kann?!

wäre klasse...und dank im voraus.

Was für code?

Statt eine SP auf dem server zu erstellen, einfach ein Sql-Befehl mit
Parametern in der ParameterCollection erstellen und gut.

Bei grösseren systemen gehen die meisten sowieso langsam in richtung ORMapper,
weshalb dann diese sachen eh egal sind.

Der ORMapper übernimmt dann die arbeit der übersetzung nach Sql.

"LinQ for Sql" NHibernate, Retina, xpo und co sind da bestimmt gute suchbegriffe.