Hi,
wahrscheinlich nerve ich die Community mit meiner Frage aber es ist für mich wirklich wichtig und um etwas dazulernen zu können -gefunden hab ich viel aber nichts durchschlagendes...
Mein Problem sieht folgend aus: Datenbank: Acces2003 mit einigen Tabellen und Indices. Windows-Form 2010. Ich würde gerne wie gehabt die DTB zu Fuß auslesen - anzeigen - bearbeiten und zurückschreiben. Da es in Vb 2010 wirklich unzählige Versionen dazu gib bin ich etwas überfordert. Ich war bis jetzt gewohnt die Datei zu öffnen, zu Benamsen und mit z.B. tbVorName.Text = rsKunden![VorName) Daten auszulesen. Diese Automation über PROJEKT > VORHANDENES ELEMENT EINFÜGEN... > DATENBANK TYP ACCESS2003-DATABASE ist mir zu undurchsichtig. Ich möchte (be)greifen können was da geschieht! Weitere Beschreibung meines Problems im folgenden PGM-Code:

PGM-Ablauf wie folgt:


Imports System.Data.OleDb
Imports System.IO
'----------------------------------------------------------------------------------------
Module Module1

Public strDatDir As String

Public conn As New OleDbConnection
Public cmd As New OleDbCommand

Public Sub DtbOpen()

strDatDir = Directory.GetCurrentDirectory & "\Daten\"

conn.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & strDatDir & "Test2003.mdb"
Try
conn.Open()
Catch ex As Exception
MessageBox.Show(ex.Message, "Fehler beim öffnen der Datenbank: " & conn.ConnectionString)
End Try

End Sub
'------------------------------------------------------------------------------------------

Public Sub DtbClose()

conn.Close()

End Sub
'-----------------------------------------------------------------------------------------------

End Module

'UND
'IN DER MID-Child-FORM
Imports System.Data.OleDb
Imports System.IO
Private Sub frmPStamm_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load

DtbOpen()

Try
Dim ds As New DataSet()
Dim da As New OleDbDataAdapter("SELECT * FROM Stammdaten", conn)
da.Fill(ds, "Stammdaten")

'und ab hier würde ich gerne "zu Fuß" den Datenbank-Table oder dasDataset
' auslesen in System.Windows.Forms.Texbox(es) einlesen, bearbeiten und dann wieder zurückschreiben.
'Bin ich vernagelt , blöd oder wahnsinnig?
'Geht das wirklich nicht über sowas wie:
'Z.B. tbFamNam.Text = Table[FamName] oder so????
'wo liegt mein Irrtum oder hab ich die Systematik noch nicht verstanden?
'Ich möchte nicht über PROJEKT > VORHANDENES ELEMENT EINFÜGEN... > DATENBANK TYP ACCESS2003-DATABASE
'da passiert viel zu viel in Hintergrund was ich nicht kontollieren kann (vielleicht noch nicht)

Catch ex As Exception
MessageBox.Show(ex.Message, "Fehler beim öffnen der Datenbank: " & conn.ConnectionString & "DataSet_frmPStamm_Load")
End Try

End Sub

Falls sich doch jemand findet der sich mit meiner Frage beschäftigt bin ich wirklich dankbar.
In der Hoffnung Antworten zu bekommen verbleibe ich
mfg
vbdido

Bitte VB-Tag benutzen - aber richtig

VBDido schrieb:

Diese Automation ... ist mir zu undurchsichtig. Ich möchte (be)greifen können was da geschieht!

Das begreift man eh nie.
Niemand auf der Welt begreift auch nur ansatzweise, was zB bei MessageBox.Show("Hallo Welt!")wirklich geschieht.
Man befindet sich immer auf einer niederen oder höheren Abstraktions-Ebene, und wenn du das toll findest, auf tieferen Ebenen herumzuwerkeln, dann wirst du das eher als Einzelkämpfer machen müssen, denn der Mainstream tendiert eher zum Einfachen, weil Einfach ist einfach einfacher ;).
Höhere AbstraktionsEbenen werden ja grad dazu geschaffen, um zu vereinfachen, also um ganze Komplexe grad nicht verstehen zu müssen, und trotzdem handeln zu können.

Den Form-Designer verwendest du doch auch, oder schreibst du seitenweise Code, um Textboxen, Labels, Panels, SplitContainer, ToolstripContainer, ToolstripItems und all das Zeugs zu erzeugen und anzuordnen?

Ja, ich bin so ein Doofkopf, weil ich Angst davor habe, was es anstellen könnte , wenn Daten an die falsche Stelle geschrieben werden. Hab eine leichte Paranoia ! Denke da an Patientendaten, Gerichtsdaten oder auch Inhaltsangaben von Lebensmittel.... man ist verantwortlich dafür wie es verwurstet wird...! Ich weiß, den meisten ist egal was dabei schief gehen kann!
Trotzdem danke für die Antwort!

mfG
vbdido

dann musst Du es wie im Defense - Bereich machen => 'nutze nichts, wovon Du nicht den Quellcode hast!' Viel Spass, das ist ein Haufen Arbeit...

VBDido schrieb:

Ja, ich bin so ein Doofkopf, weil ich Angst davor habe, was es anstellen könnte , wenn Daten an die falsche Stelle geschrieben werden.

Ja, nee, dassis unbedingt richtig, dass man mit Sicherheits-Aspekten absolut verantwortlich umgeht.

Und bei so höheren Abstraktions-Ebenen muß man halt drauf vertrauen, dass die Technologien so funktionieren, wie sie dokumentiert sind, und nicht anders.
Aber man kann da auch drauf vertrauen, denn in diesen Technologien steckt ein schier unvorstellbares Ausmaß an Man-Power, und nicht irgendwelche Männlein, sondern da hocken Profis dran, mit einem KnowHow und mit Erfahrung, wo vmtl. von allen VBP-Usern kein einziger mithalten könnte.
Und die Dinger sind ja vertrieben, und bereits jahrelang im Produktiv-Einsatz, und dassis halt der gründlichste Test auf Verlässlichkeit überhaupt.

Also ich sehe das SicherheitsProblem grad umgekehrt: Indem du auf die für ein best. Problem vorgesehenen Lösungs-Ansätze verzichtest, gefährdest du die Sicherheit, denn grad im DB-Bereich sind die Probleme so komplex, dass sie auf niederen AbstraktionsEbenen garnet mehr handelbar sind.
Also für ein Datenbänkle mit mw. 2 Tabellen, insges. 20 Spalten und einer relationalen Beziehung kannst du mw. mit 500 Zeilen Code die basic CRUD - Funktionalität noch implementieren, indem du für jede Tabelle Sql-Commands bastelst, und mit DataReadern das Zeug einliest und schön auf die Zellen in DataGridViews verteilst usw. usf..

Aber schon bei 10 Tabellen, 100 Spalten, 15 Relationen isses eiglich nicht menschenmachbar. Und grad die "Kontrolle" geht dabei als erstes verloren, oder meinst du, du hättest beinem Code-Monstrum von 10000 Zeilen die Kontrolle?
Und das bei paar mehr Tabellen ja üblicherweise auch mehrere Forms zu gestalten und verwalten sind, habichjetzt noch nichtmal erwähnt.
Also es ist grad umgekehrt: Die Kontrolle behälst du nur, indem du die abstrakteren Technologien zu beherrschen erlernst - anders nicht.
Ist halt Arbeit sich in das Zeugs einzuarbeiten, aber Arbeit wirds so oder so: auch deine 10000 Zeilen schreiben sich nicht alleine.

ErfinderDesRades schrieb:

Aber man kann da auch drauf vertrauen, denn in diesen Technologien steckt ein schier unvorstellbares Ausmaß an Man-Power, und nicht irgendwelche Männlein, sondern da hocken Profis dran, mit einem KnowHow und mit Erfahrung, wo vmtl. von allen VBP-Usern kein einziger mithalten könnte.

Das ist sicherlich richtig! Ich bin es halt gewohnt alles selber zu machen und bin höchstwahrscheinlich zu träge und ängstlich erlernte Gewohnheiten umzustellen. Du hast auch Recht, dass es sehr aufwändig ist all die Tabellen und Spalten zu verwalten. Bei mir sind es bereits 38 Tabellen und und über 300 Spalten! Tja, was soll's! Noch läuft meine alte Version und für die Umstellung hab ich noch Zeit. Diese Zeit werde ich nutzen und mich in die 'neue' Materie einarbeiten, bis ich genug Vertrauen in mich und die Wunderwuzzis habe. So wie es aussieht wird es eine Mischform werden, falls machbar!
Vielen Dank für deine konstruktiven Meldungen!

VBDido schrieb:

38 Tabellen und und über 300 Spalten! ... Umstellung ... wird es eine Mischform werden, falls machbar!

Da seh ich schwarz.
Ein großes Projekt kann man nur dann auf annere Füße stellen, wenn die Architektur von anfang an daraufhin konzipiert ist, "Füße auszuwechseln". Das nennt man den Strategy-Pattern.

Unds ist katastrophal schwer ein fertiges Teil umzustellen, und wenn man sich erst einarbeiten muß ists ganz unmöglich.

Einarbeitung muß an einfachen Beispielen erfolgen, sonst hat man keine Chance, es richtig zu lernen. Dassisja das Problem mittm lernen: Man lernt ja immer. Und wenn man Bockmist baut, dann lernt man eben dieses. Und davor gibts auch keinen Schutz, ausser der Bockmist geht vorn und hinten überhaupt nicht auf.

Also vom Lernen her wäre am besten, erstmal anhand einfacher Beispiele.
Dann ein neues Projekt von vornherein sauber aufziehen, und dann erst hat man vielleicht(!) soviel Erfahrung, dass man sich trauen kann, das zwar zurechtgewurstelte, aber doch stabil laufende System umzufrickeln.

Bei DB-Anwendungen, die ohne Databinding entwickelt wurden, läufts eh auf eine Neu-Entwicklung hinaus, denn wenn man iwann die Logik gebundener Oberflächen geschnackelt hat, dann weist man keiner Textbox mehr einen Text zu, und tut kein Item mehr in eine Combobox.

Also allererster Einstieg könnte Datenbänkerei-Einstieg und weiterführende Links sein.

Die volle Dröhnung gibts dann bei vier Views

@ErfinderDesRades
Ich hab mir deine Anregungen zu Herzen genommen und habe begonnen die Datenbankstruktur zu überarbeiten, überschaubarer zu machen - wartungsfreudiger. Habe bereits einige Tables überarbeitet, hinzugefügt und dokumentiert. Füge Bezeichnungen dazu (Access 2003) und checke jedes Eingabefeld plausibel ab. Da ich einen Debug-Modus mit CommandLineArgs dazugefügt habe und Hilfsfelder dann angezeigt bekomme, fühle ich mich recht sicher und auf dem richtigen Weg. Ich 'kann überprüfen' ob die Befehlskette richtig schreibt und liest. Vertrauen gehört auf alle Fälle auch dazu.
Deine Links sind spitzenmäßig und helfen mir wirklich weiter, bzw. bestärken mich in meinem Tun.
Nochmal vielen Dank für dein 'Mitdenken'!
mfG
vbdido