auf Form1 fährt wohl ein anderes SqlControl herum als auf Form2.
ich weiß nicht, was ein SqlControl ist, könnte mir aber vorstellen, dass das eine richtig eingerichtet ist, das andere nicht.

Wärst du eiglich daran interessiert, Databinding zu erlernen, DataAdapter für dich arbeiten zu lassen, und vor allem Sql-Injection -Angriffe zu vermeiden (folge dem Link - dein Ansatz ist ein gefundenes Fressen für Sql-Injekter)?

also im ersten post ist mir schon aufgefallen, dass du im SqlControl die Connection disposest.
Dann ist mir plausibel, dass sie beim 2. Mal nicht mehr funktioniert.

Aber das ist ganz unwichtig. Sieh erstmal zu, dass du deine Anwendung DatasetOnly aufgebaut kriegst.
Eine Datenbank kann man später da immer noch hinterlegen, und das geht im übrigen ganz anders, wenn mans effizient haben will und v.a. sicher gegen SqlInjection.

Aber eins nachm anneren, und die Db ist einfach längst noch nicht dran. Konzentrier dich auf DatasetOnly, weil was du hier am Db-Zugriff rumhudelst, musst du später eh wieder in die Tonne treten.

Noch ein Tipp: Fang nicht gleich mit 2 Forms an - zwei Forms richtig zu handeln ist ziemlich tricky. Eins nachm anneren.

Ja, wenn du das Datenmodell änderst zieht das auch Änderungen im Code nach sich.
Etwa die AddBonRow verlangt dann einen Wert für den Kunden, dem sie zugeordnet werden soll.

Akanel schrieb:

Eigentlich wird doch die KundenID in der Tabelle Bon von der Tabelle Kunden übernommen (Relation).

Nein, denn woher soll der Bon-Datensatz denn wissen, zu welchem Kunden er gehören soll? Das musst du ihm schon sagen.
Und daraus ergibt sich ein weiterer Effekt: Du wirst keine Bons mehr so anlegen können.
Zunächstmal müssen Kunden angelegt sein, denn - so das neue Datenmodell - ohne Kunde kein Bon.

Tatsächlich ist dann sogar die Bezeichnung "Bon" irreführend, denn eiglich handelt es sich in dem Moment, wo Bons Kunden zugeordnet sind, nicht mehr um Bons, sondern um Rechnungen.
Und dann ist auch ganz menschlich logisch: Ohne Kunde kann es keine Rechnung geben. Und genau so verhält sich auch das Datenmodell.

Also für dein Rechnungs-Programm brauchst du eine andere Oberfläche, eine, wo man zunächst Kunden anlegt und auswählt (kann im selben DGV passieren), und dann einen ParentChild-View, der von einem Kunden die Rechnungen (was früher Bon war) auflistet.
(Übrigens, indem du Kunde->Rechnung als ParentChildView umsetzst, machst du tatsächlich den Rechnungen immer ihren Kunden bekannt, also tatsächlich kann mans so einrichten, dass die Rechnung den gemeinten Kunden automatisch übernimmt - aber man musses halt so einrichten.

Jdfs freut mich regelrecht, dass du von dir aus die Datenbank nu zurückstellst, und dich erstmal dem widmest, was man tatsächlich vorher geschnackelt haben muss, um eine Datenverarbeitung aufzuziehen: nämlich Datenmodellierung und Databinding.
Hab ich 2 Tuts zu:
Datamodel for Beginners das sind 3 Artikel, die den ganzen Themenkomplex von Grund auf aufarbeiten
vier Views-Videos das ist auf Deutsch, mit viele Videos - wenn man Vorkenntnisse hat, kann man damit evtl. superschnell einsteigen, aber ich empfehle eiglich lieber das gründliche auf englisch.
Auf jeden Fall reingucken, um ein Feeling zu kriegen, worauf es hinausläuft, und wie verblüffend einfach es ist, wenn man die Prinzipien einhält, und ausserdem die Designer-Unterstützung für sich arbeiten lässt.

Kannst du vlt. noch die bin-Ordner aus dem Upload rauswerfen?
Die enthalten ausführbare Dateien, und derlei sollte man eiglich nicht uploaden. Ist auf VBP auch nur im ShowRoom erlaubt.

Ich kann dir auch ein Tool von mir empfehlen, damit kann man mit einem Klick die Sources zippen - ausschließlich die Sources.
Verwende ich sehr viel für Backups, und Backups sind enorm wichtig.
Vor jedem größeren Umbauschritt sollte man mal drauf-klicken - einerseits falls die IDE sich mal verhaspelt, andererseits, um Vergleiche anstellen zu können, wenn man späterhin merkt, dass man was verschlimmbessert hat

Zum Prob mit dem Kunde anlegen: Du hast da unten links ja einen DetailView mit viele Labels.
Wenn du stattdessen Textboxen nimmst, dann kannst du Kunden vernünftig anlegen + editieren, glaub ich.

SolutionExplorer - OpenSource

Akanel schrieb:

Das problem das ich im moment habe ist eine Rechnung zu erstellen, wenn schon ein Kunde vorhanden ist.

Das "Problem" verstehe ich nicht.
Ist doch gut, wenn ein Kunde schon vorhanden ist!

Wie gesagt - anders kann man logischerweise gar keine Rechnungen erstellen - wie soll man denn ohne Kunden eine Rechnung erstellen?

bzgl der Rechnung: ich sehe kein Problem - ich kann Rechnungen zufügen, ändern löschen speichern laden - wie sichs gehört.

(achte auch auf die Größe des Uploades - SolutionExplorer zippt wirklich nur das nötige)
(beachte auch, dass die Daten-Datei gleich mit drin ist - auch im SolutionExplorer sichtbar)

ich weiß jetzt nicht sicher, was der Parameter br bedeutet, aber rect3 könnte doch sein, dass das ein Rechteck ist, in das hineingedruckt wird?
Wenn man da rect3.Y erhöht, sollte der gezeichnete String ein Stück tiefer kommen.

Aber kann auch entscheidend sein, zu erfahren, was br ist.

also dann proggst du wohl noch strict off, und bist dir deshalb nicht im Klaren darüber, was die DrawString-Methode eiglich für Parameter erwartet. Dass sie einen "Bruch" - was immer das sein soll, als vorletzten Parameter annimmt, halte ich für nahezu ausgeschlossen - da wird wieder sone unsichtbare strict-off-TypConvertierung stattfinden.
Machma Rechtsklick auf "DrawString" und dann "zu Definition gehen" - das sollte den ObjectBrowser öffnen, und die genaue Definition der Methode angeben, die du da aufrufst.
Die Summary und weitere Erklärungen kannste unten rechts auskopieren, und hier posten.

Falls du ObjectBrowser noch nie gesehen hast: VisualStudio richtig nutzen (Google ist nicht deine Mami)