Designer-Code

[cb4866]

Hallo liebes Forum,

kann man einen Teil des "NonUser-generated" Codes eines DataSets im partiellen "User-Teil" überschreiben?

<Global.System.Diagnostics.DebuggerNonUserCodeAttribute()> _
PrivateSub InitCommandCollection()
Me._commandCollection = NewGlobal.System.Data.OleDb.OleDbCommand(1) {}
Me._commandCollection(0) = NewGlobal.System.Data.OleDb.OleDbCommand
Me._commandCollection(0).Connection = Me.Connection
Me._commandCollection(0).CommandText = "SELECT GUIDJagdgebiet, intJagdgebiet, strJagdgebiet, fkJagdArt, intDBForstdirektion, strDbBhJagdDb, strBhIdentifikation, lngBhJagdNummer, lngBezirkJagd, boolAbschussplan, boolVuwBeurteilung, lngFlächeGesamt, lngFlächeWald, lngFlächeSchutzwald FROM tbl2100GuidJagdgebiet WHERE boolVuwBeurteilung = -1"
Me._commandCollection(0).CommandType = Global.System.Data.CommandType.Text

EndSub

konkret würde ich gern den CommandText für grundlegende Einstellungen individuell (User-abhängige WHERE - Klausel) gestalten wollen. Geht das?

liebe Grüße
Christian

[Jürgen Thomas]

Hallo Christian,

im non-Designer-Teil einer Klasse kannst Du bedenkenlos Änderungen vornehmen - Eigenschaften überschreiben, eigene Methoden hinzufügen usw. Die einzigen Einschränkungen, die Du unbedingt beachten solltest, sind: bei einer Form.Designer.* darfst Du erst nach InitializeComponents() eingreifen, in einer DataSet.Designer.* erst nach dem Konstruktor. (Das ist keine theoretische Einschränkung, aber ich kann mir in der Praxis keine Abweichung davon vorstellen.)

Änderungen des CommandText und auch des ConnectionStrings gehören unbedingt zu diesen Maßnahmen. Es macht ja auch keinen Sinn, jeden denkbaren Select-Befehl durch den Designer vorzumerken.

Jürgen

[cb4866]

Hallo Jürgen,

danke für deine Antwort!

Vielleicht sollte ich meinen Gedanken etwas genauer beschreiben und das Szenario noch etwas erweitern:

Stell dir eine MS-Access Datenbank mit rund 50 Tabellen vor, einige davon sind MasterTabellen mit ihnen verknüpft die FremdschlüsselTabellen.

Auf diese Datenbank greift eine Zentralstelle (mehrere User) und rd. 10 hierarchische Aussenstellen (1 Leitung und mehrere "Datenlieferanten") zu.

im Prinzip arbeitet jeder im selben System mit (fast) den selben Formularen, nur eben mit einer mehr oder weniger eingeschränkten Sicht auf die Daten.

Darum hätte ich mir gedacht, könnte man doch je nach dem wer ins System "einsteigt" gleich von vornherein das DataSet mit mehr oder weniger Tabellen mit mehr oder weniger umfangreichem Inhalt erstellen lassen.

Mir ist bekannt, dass man von einer DataTable verschiedene DataViews erstellen kann, und die Daten auf diese Weise filtern und eingeschränkt zur Verfügung stellen kann.

Die Beschränkung der Datenmenge wäre mir deshalb ein Anliegen, weil ich die Erfahrung gemacht habe, dass mit steigender DataTable-Anzahl im DataSet die Leistungsfähigkeit (Performance) des Systems - (lange Ladezeiten) spürbar zurückgeht!

Vielleicht liege ich ja wieder einmal daneben - und es gibt dafür eine ganz andere Strategie?

Grüsse
Christian

[Andreas Kosch]

Hallo,

...weil ich die Erfahrung gemacht habe, dass mit steigender DataTable-Anzahl im DataSet die Leistungsfähigkeit (Performance) des Systems - (lange Ladezeiten) spürbar zurückgeht.

dieser Satz gilt nur dann, wenn zur Laufzeit alle DataTable-Instanzen im DataSet mit allen Datensätzen gefüllt werden (d.h. die SELECT-Abfrage verwendet kein geeignetes WHERE-Kriterium).

..gleich von vornherein das DataSet mit mehr oder weniger Tabellen mit mehr oder weniger umfangreichem Inhalt erstellen lassen.

Die Anzahl der DataTable's ist nicht das Problem, sondern das "richtige" Füllen ;-)

Wenn ein typisiertes DataSet verwendet wird und der TableAdapter über den Designer mehrere Fill-Methoden mit passenden WHERE-Einschränkungen erhält, kann das Programm je nach dem vorgefundenen Anwender die passende Fill-Methode aufrufen. Jeder Benutzer erhält somit eine eigene Sichtweise auf den gemeinsam genutzten Datenbestand.

Im Fall einer MS SQL Server-Datenbank hätte ich für den TableAdapter nur gespeicherte Prozeduren verwendet, die als Parameter die Benutzerkennung erhalten und den Datenbestand direkt über WHERE-Einschränkungen filtern.

[cb4866]

Verständnisfrage zu "Stored-Procedures"

Hallo Andreas,

ich versuche dich zu verstehen - allein es gelingt mir nicht - danke für die Verwirrung !

interpretiere ich dich richtig, wenn ich nun die Sachlage in der Weise sehe,

• dass ein typed Dataset die Möglichkeit der Feinabstimmung im Bereitstellen von Daten in der Weise einschränkt, als es zur Laufzeit nur den Zugriff auf zur Entwurfszeit definierte Fill-Methoden erlaubt?
• dass wenn man als Datenbanksystem den SQL-Server verwendet, das typed-Dataset, wegen der Möglichkeit Stored-Procedures einzusetzen, nicht verwendet werden muss oder soll?
• dass es für den "normalen" Zugriff auf einen OleDb-Provider, sofern man die .Net-Vorzüge der aufeinander abgestimmten Komponenten und Methoden nutzen möchte der "Kampf" mit dem typed-DataSet das "kleinere Übel" ist?

liebe Grüsse
Christian

[Ralf Jansen]

dass ein typed Dataset die Möglichkeit der Feinabstimmung im Bereitstellen von Daten in der Weise einschränkt, als es zur Laufzeit nur den Zugriff auf zur Entwurfszeit definierte Fill-Methoden erlaubt?

Nimmand hindert dich daran den Tableadapter der ja eine partielle Klasse ist beliebig um eigene Fill Methoden zu erweitern. Dort hast du die Freiheit den Commandtext beliebig zu ändern. Kopier dir doch einfach eine aus der Designer Datei und andere sie nach deinem Gusto.

dass wenn man als Datenbanksystem den SQL-Server verwendet, das typed-Dataset, wegen der Möglichkeit Stored-Procedures einzusetzen, nicht verwendet werden muss oder soll?

Stored Procedures sind einfach eine weitere Möglichkeit des Zugriffs. Aber nicht das allein glücklichmachende. Ob du deinen Zugriff lieber/besser in der Anwendung oder in der DB steuerst hängt von vielen Faktoren ab.
Es gibt aber kein Zusammenhang zwischen der Entscheidung für oder gegen TypedDatasets und der Entscheidung für oder gegen Stored Procedures. Die sind meines erachtestens unabhängig.

dass es für den "normalen" Zugriff auf einen OleDb-Provider, sofern man die .Net-Vorzüge der aufeinander abgestimmten Komponenten und Methoden nutzen möchte der "Kampf" mit dem typed-DataSet das "kleinere Übel" ist?

Definiere "normal". Vorgefertigte Komponenten bringen immer auch ein vorgefertigtes Vorgehensmodel mit wie man sie denn benutzen solllte. Wenn man diesem seine eigene Vorstellung aufpfropft wird die Benutzung meißt zum Kampf, je nachdem wie weit die eigene Vorstellung abweicht.

[cb4866]

Hallo Ralf,

merci für die Aufklärung!

-> "normale Anbindung an einen DbProvider" - vermutlich hast du recht damit, dass normal ganz schön untschiedlich normal sein kann!

Danke einstweilen,

Grüsse
Christian