Hallo zusammen,

ich bin neu hier und habe bis jetzt einiges in Excel per VBA gemacht. Jetzt möchte ich weiterkommen und meinen Horizont erweitern.
In meiner Firma haben wir eine Art Prüffragenkatalog der in Excel erstellt ist und per VBA eine Bestandskontrolle von Waren durchführt selbstständig Emails an bestimmte Verteiler verschickt usw. Prüffragen müssen markiert werden so das am Ende ggf. Punkte abgezogen werden.

Da Excel eher der Rechenknecht ist und wir da eigentlich "nur" eine Datenverarbeitung vornehmen und das bisher Programmierte teilweise schon fast zehn Jahre alt ist würde ich das Ganze gern in VB.Net als eigenständiges Programm erstellen.

Jetzt habe ich dinge generelle Frage. In Excel kann ich Felder befüllen, diese abspeichern, wieder aufrufen per Sverweiss auf andere Excel-Mappen zugfreien usw.
Wie aber löst ich das in VB? Wo speichere ich Dinge ab. In Textdateien? Oder wieder in Excel-Mappen? Oder lokal in einer Datenbank? Mein Traum ist es jede gemachte Prüfung in eine Datenback zu schießen. Ich hoffe ihr versteht um was es mir gerade geht?

Vielen Dank für konstruktive Impulse.

Gruß, Mac

Verschoben. ~Thunderbolt

Zum Speichern der Daten gibt es natürlich viele Möglichkeiten, die Frage ist natürlich immer in wieweit diese sinnvoll sind

-> Textdatei


-> XML


-> Access


->SQL Datenbank


So viel mal dazu es liegt natürlich immer am Entwickler zu entscheiden, welche Möglichkeit schlussendlich für sein Problem die beste ist. So können auch XML-Dateien sinnvoll eingesetzt werden (Dafür wurden sie ja erschaffen)

Daten in eine Excel-Datei zu speichern habe ich hier gezielt nicht aufgegriffen, da diese Methode noch umstrittener als Access-Datenbanken sein dürfte

Da dein Traum aber ja schon in Richtung Datenbanken geht kann ich nur empfehlen MySQL-Datenbanken etwas genauer anzuschauen => mysql.de/ <=

Hoffe das bringt dich schon mal weiter ...

@Macfly123 Deine Aufgabe ist es als erstes, bevor du überhaupt etwas anfängst, die Datenstruktur der bestehenden Excel-Tabellen zu erfassen. Dafür erzeugst du dir ein Projekt, klatschst ein DataSet rein und baust dort die Tabellen zusammen, die die Datenstrukturen wiedergeben. Danach schaust du dir an, was wann und zu welchem Zeitpunkt gemacht wird. Du wirst einige Zeit keine einzige Zeile Code schreiben sondern nur analysieren, nachbauen und dokumentieren. Mach dich darauf gefasst.

Wenn dann irgendwann mal alles in einem typisierten Dataset zusammengefügt ist, und auch der Quellcode exakt das Tut, was der VBA Teil der Excel-Mapen tut, DANN kannst du noch ne Datenbank hinter das DataSet legen. Das sind nur ein Paar Zeilen Code.

Falls du mehr wissen willst, zum Thema DataSet und Co., such nach den Tutorials und Erklärungen von @ErfinderDesRades Die sind überall durchs Board verstreut un können praktisch nicht übersehen werden

EaranMaleasi schrieb:

Die sind überall durchs Board verstreut

naja, im Datenbank-Tutorial-Bereich treten sie schon bisserl gehäufter auf.

Weiters traktiere ich jeden Anfänger mit 2 wichtigen Links:
1) Visual Studio - Empfohlene Einstellungen - das ist das aller - aller - notwendigste, am besten, bevor man ühaupt eine Zeile Code hinschreibt.
Und für Ex-VBA-ler gilt das umso mehr, denn vb.net ist nicht vba, aber als Ex-vba-ler ist man noch viel stärker der Versuchung ausgesetzt, diesen Unterschied zu ignorieren.
2) Datenverarbeitungs-Vorraussetzungen
Das ist quasi das ganze Programm. Letztendlich ists genauso notwendig wie 1), weil ohne ein Datenmodell programmieren zu können, kann man halt keine Datenverarbeitung programmieren - Jedenfalls keine, über die man nicht die Hände überm Kopf zusammenschlüge.

EaranMaleasi schrieb:

Wenn dann irgendwann mal alles in einem typisierten Dataset zusammengefügt ist, und auch der Quellcode exakt das Tut, was der VBA Teil der Excel-Mapen tut, DANN kannst du noch ne Datenbank hinter das DataSet legen. Das sind nur ein Paar Zeilen Code.

also grundsätzlich habe ich es auch so gemacht und bilde mich hier und durch herrn löffelmann bereits seit 3 jahren erfolgreich weiter,
das mit den paar zeilen stimmt imho aber nur wenn du die db extensions von edr nimmst.

ansonsten war es mir noch nicht vergönnt ein dataset mit ein paar relationen mal so eben in zb eine access db zu schaufeln.
ich wäre aber sehr erfreut wenn ich hier weiter kommen könnte

Welche Art von Dataset verwendest du? Abeitest du mit typisierten DS...

VB1963 schrieb:

Welche Art von Dataset verwendest du? Abeitest du mit typisierten DS...

ich nehme an du meinst mich
ja habe nur typ ds, habe nach den vier views und den vielen ratschlägen hier im board gearbeitet.

mein problem bestand darin, die tabellen in einer access db in der korrekten reihenfolge ab zu fahren. das habe ich bis heute nicht zufriedenstellend zu ende gebracht. musst aber auch verstehen ,dass ich nicht die db extension von edr nutze, da ich gerne verstehen möchte was im hintergrund passiert.

edit: nachtrag: ein hab ich vergessen zu erwähnen, ich habe den db generator von edr benutzt um die access schmerzfrei zu erstellen (nach fertigstellung des datasets)...

hans im glück schrieb:

die tabellen in einer access db in der korrekten reihenfolge ab zu fahren. das habe ich bis heute nicht zufriedenstellend zu ende gebracht

Da sind ja die DB-Extensions gerade im Vorteil...

MSDN schrieb:

Um zu verhindern, dass Integritätsfehler ausgelöst werden, wird bei der Aktualisierung der Datenbank die folgende Reihenfolge empfohlen:
[1] Untergeordnete Tabelle: Datensätze löschen.
[2] Übergeordnete Tabelle: Datensätze einfügen, aktualisieren und löschen.
[3] Untergeordnete Tabelle: Datensätze einfügen und aktualisieren.

msdn.microsoft.com/de-de/libra…cs-lang=vb#code-snippet-1

hans im glück schrieb:

die tabellen in einer access db in der korrekten reihenfolge ab zu fahren.

also hier die Speicher-Methode der DbExtensions:Ist Haufen Brimborium dabei, aber das Prinzip kann hoffentlich erkennbar gemacht wern:
Zunächstmal müssen die Tabellen von vornherein in eine widerspruchsfreie Reihenfolge gebracht sein, also eine per Relation untergeordnete Tabelle darf keinesfalls vor ihrer ParentTable eingeordnet sein. Das ist an anderer Stelle mit einem listigen Sortiervorgang (topologische Sortierung) gelöst, aber wenn du deine SpeicherFunktion selbst schreibst, kannst du auch durch Kopfdenken eine gangbare Reihenfolge finden (sind meist mehrere möglich), und deine Tabellen entsprechend geordnet übergeben.
Jo, denn gugge code:

1. zuerst in einer Schleife (#8-#11) werden alle addeten und modifiedeten Rows geupdatet(#10), und zwar nudelt die Schleife alle Tabellen durch (in wie gesagt richtiger Reihenfolge).
   
2. Dann werden die AcceptRules aller Relationen auf Cascade umgestellt (#13). Dafür habich eine Extra kleine Klasse gebaut - siehe unten.
   
3. DAnn werden alle Tabellen nochmal durchgenudelt, in gleicher Reihenfolge, und die verbleibenden Deletes werden auch geupdated - #14 - ist ja auch drankommentiert.
   
4. Dann die AcceptRules wieder zurückstellen #15.
   

Also das Prinzip ist allgemeingültig, und man kann sone Routine auch selber coden. Wie gesagt - bei mir ist da viel Brimborium dran, das mit der Transaction, das mitte DataTableAttaches, wo DataAdapter drinne sind, und registrierete BindingSources, die während des Addens auch suspendiert werden (#7, #12), und so Sachen.
Aber anfangen kannste ja mit diesen beiden Schleifen.
Du müsstest deiner Methode halt die DataTables übergeben, und zu jeder DataTable auch den zugehörigen DataAdapter.
Jo, das mitte AcceptRules, da kann man auch dran hirnen - oder du gibst als 3. Element halt auch die betroffenen Relationen an, die temporär auf Accept.Cascade zu setzen sind.
Naja, oder halt generisch ist wohl doch am einfachsten, kannste ja das Dingens von mir für übernehmen:

@VB1963: Den MSDN-Algo findich nicht optimal, der nutzt nicht aus, dass eine DB selbst Löschweitergabe eingebaut haben kann (sollte). Dadurch entsteht unnötiger Traffic.

Hallo zusammen,

ich merke gerade ich steh völlig am Anfang, bin etwas demotiviert und blöde drein schauend. Ich will alles geil machen, in einem eigenständigen Programm und merke, dass das alles andere als leicht sein wird. Aber ich will was hinterlassen, was geiles abliefern wo alle sagen "Hammer der Typ" Vielleicht weiß jemand was ich meine. Ich weiß was ich will, wie escaussehen soll usw. aber mein nicht vorhandenes Wissen über Visual Studio und SQL steht mir im Wege. Ich frage mich gerade auch wie zum Beispiel ein Inventurrtool aussehen könnte? In Excel wurde der Warenbestand importiert. Dann wird über eine Zelle ein Barcode eingescannt. Der wird mit den vorhannden Barcodes verglichen und bei Übereinstimmung die Ist-Wert hochgezählt. Wenn der Ist-Wert ond der Soll-Wert gleich sind wird die Zeile mit dem Artikel grün markiert. Ich weiß nicht mal wie ich das in WindowsForm ausgeben könnte wenn ihr versteht was ich meine.

Sind Datasets so eine Art Container für Daten aus der Datenbank? So eine Art Zwischenspeicher um nicht immer wieder die Datenbank zu connecten?

Ich habe einen Videolehrgang von video2brain durchgearbeitet. Alles sehr gut erklärt. Z.B. Schleifen, Variablen, Operatoren, also auch schon einiges was ich kannte. Aber nichts von Datasets, oder das arbeiten mit SQL Datenbanken usw.
Daher die Frage wie würdet ihr an meiner Stelle vor gehen um das alles möglichst schnell auf die Schippe zubekommen? Welche Bücher kennt ihr und würdet ihr Empfehlen? Ich arbeite mit Visual Studio 13 - Express. Was sollte ich als erstes lernen? Ich kenne bereits Schleifen, Variablen, Datentypen, If-Anweisungn, Case Select usw.

Ich hatte vor kurzem eine VBA-Schulung. Hier hätte ich mal lieber VB nehmen sollen. Aber da war das alles noch nicht so klar. Nich klar, dass ich diese Sachen übernehmen soll. In Excel kein Problem aber ich will ja weg davon.
Ich brauch glaube ich so einige Impulse und Gedankenstützen und bedanke mich schon im vorraus herzlichst bei euch.

Viele Grüße, Mac

zumindest ein Trost: Schulungen taugen meist nix. ob Excel weiß nicht, aber die .Net-Sprachen... hatte gelegentlich entsprechende kleine Einblicke.

Macfly123 schrieb:

Sind Datasets so eine Art Container für Daten aus der Datenbank? So eine Art Zwischenspeicher um nicht immer wieder die Datenbank zu connecten?

Das ist eine ausgezeichnete Beschreibung einer der Haupt-Eigenschaften von Datasets.
Aber es ist nur eine Haupteigenaschaften, das typisierte Dataset (wichtige Unterscheidung!!) hat noch 2 weitere Haupt-Eigenaschaften: a) Typisierung b) Databinding-Unterstützung
Das schnellste, ums auf Schippe zu kriegen nannte ich bereits in post#4.
Wie stehts damit - hast du die Deppen-Einstellungen inzwischen behoben?
Und dann fang mit dem anderen Link an.

Und fixier dich nicht zu sehr auf wie du dir das vorstellst. Eine Datenverarbeitung entwickelt man vom Datenmodell ausgehend, und die ersten Versionen sehen zT. grauenhaft aus, aber wenn sie ihren Job machen, ist man eiglich schon übern Berg.
Irgendwelche Artikel iwan grün markieren ist hübsches Gimmik. Wird auch unterstützt, aber wenn die Struktur nicht hinhaut, kommst du garnet so weit (bzw wirst später doch alles wieder in Tonne treten müssen).
Lies die verlinkten Artikel gründlich, und merk dir insbesondere, dass du mit Sql und Datenbanken überhaupt nichts zu tun hast - jedenfalls nicht, wenn du zügig vorankommen willst.
Viele können das nicht fassen, wird mir auch fleissig drin widersprochen - also lies die verlinkten Artikel, lies meine Argumentation (hier: unter Vorbemerkung), dann kannst du dich ja immer noch mit Datenbanken verzetteln.

@Macfly123 so gehts mir heute nach nun mehr als 3 Jahren noch
les das löffelmann buch und frag hier, dann kommst du auch weiter. wenn du die oben genannten grundlagen hast kannste dir was die daten angeht die vier views videos anschauen, das thema datenbank kommt dann mal ganz zum schluss wenn die gesamte anwendung bereits mit typ ds und einer xml als speicherdatei funktioniert.
@ErfinderDesRades
ich möchte gerne nochmal auf deinen code zurück kommen. du hast natürlich die absolute deluxe variante gecodet, also im prinzip egal wieviele tabellen im ds die auch noch automatisch sortiert werden usw...

wenn ich nun aber (ausgehend von der behauptung dass das datenmodell wirklich fertig ist) alle meine tabellen genau kenne, wäre doch dann das msn prinzip egtl. auch in ordnung oder?

ich meine diese abfolge:




was bei mir auch noch der fall ist: in meiner anwendung habe ich gegen deinen ratschlag die löschweitergabe nicht aktiv! es wäre einfach fatal wenn ein anwender mal eben einen kunden löscht, den Dialog auch nochmals zufällig durch amokklicken bestätigt und dann alle datensätze (in meinem fall geräte) zzgl. aller messdaten pro gerät weg sind.
daher habe ich mich entschieden dass erst child rows gezielt gelöscht werden müssen, also eine parent row darf keine child rows mehr haben.

dann habe ich doch auch nicht oben genanntes performance problem oder?

hans im glück schrieb:

wäre doch dann das msn prinzip egtl. auch in ordnung oder?

jo, das msdn-Prinzip ist auch bischen einfacher umzusetzen - man muss halt nix an den Relationen rumschrauben.
Aber nachwievor musste die Tabellen in die richtige Reihenfolge bringen, und musst den Tabellen natürlich auch den richtigen TableAdapter zuordnen.

Und in der msdn-Variante musste die Deletes isolieren, und "bottom-up" updaten. D.h. die (topologisch geordnete) List(Of DataTable), die du brauchst, rückwärts durchlaufen.
Den Rest dann vorwärts durchlaufen und updaten. Dabei brauchst du nicht zw. Added und Modified unterscheiden - tatsächlich kannst du sogar die ganzen Tabellen reinschmeissen.
Weil die Deleteds die setzen nachem Update ja automatisch ihren RowState auf Accepted, die werden also in der 2. Update-Runde garnet erfasst.

Sehr lästig wirkt sich jetzt die Typisierung der typisierten TableAdapter aus, weil die kann man garnet in eine gemeinsame Liste packen - da muss ich nochmal gucken, ob man da was drehen kann.
Also typisiertes Dataset ist absolutes Muss, aber die typisierten TableAdapter sind eine Krankheit.
Aber gibts da nicht auch diesen abstrusen TableAdapterManager? Der hat doch auch eine UpdateAll-Methode - funktioniert die nicht?

ErfinderDesRades schrieb:

Aber gibts da nicht auch diesen abstrusen TableAdapterManager? Der hat doch auch eine UpdateAll-Methode - funktioniert die nicht?

naja die bekomme ich ja nur dann wenn ich eine fertige db importiere generiert.
ich habe ja ein dataset erstellt, würde zur laufzeit mit deinem db generator erzeugten sql code nutzen um die access db zu erzeugen und dann die tableadapter zur laufzeit pro tabelle anlegen.

so hab ich meine ersten tests ausgeführt.

oder habe ich da was falsch verstanden?

Das heißt also, das Thema Sql & Datenbanken sollte ich erstmal ruhen lassen und das ganze erst mal lokal bauen?
Das mit dem Strict On wurde bereits in dem erwähnten Videotraining beschrieben und erklärt. Hab ich also eingestellt.

Soll ich mich also erstmal mit dem speichern in XML-Dateien auseinandersetzen? Was wäre hier sinnvoll?

Wie gesagt mach mal die vier views von edr durch (youtube Videos, glaub im Thread Datenverarbeitung einfachste Variante oder sowas in der Art, würde den Link ja einstellen bin aber mobil unterwegs). Wenn du dann deine controls auf dem form an ein typisiertes ds gebunden hast ist das speichern mit ein paar Zeilen und einem Save file Dialog erledigt.

Wenn deine anwendung dann mit dem fertigen dataset dsfunktioniert kannste dir am Schluss Gedanken zur richtigen dB machen (siehe die Diskussion die ich grad führe)

Macfly123 schrieb:

Das heißt also, das Thema Sql & Datenbanken sollte ich erstmal ruhen lassen und das ganze erst mal lokal bauen?
...
Soll ich mich also erstmal mit dem speichern in XML-Dateien auseinandersetzen? Was wäre hier sinnvoll?

Wie in post#11 bereits gesagt: Kaum einer kann es fassen, aber es ist so.
Wenn du mir einen Gefallen tun magst: Lies sorgfältig, was ich schreibe, und nimm es ernst.
Dann hätten diese Fragen eigentlich nicht auftreten können. Ich habe eine Neigung, vergleichsweise schnell angepisst zu reagieren, wenn ich dasselbe nochmal erzählen muss, was ich zuvor bereits haarklein und unmissverständlich auseinandergesetzt habe.
Da ist mir Widerspruch lieber, weil wer mir widerspricht, nimmt wenigstens ernst, was ich sage.
Hingegen wer nur fragt, ob das wirklich so gemeint ist, was ich schrieb... - ja, es ist so gemeint, wie ichs geschrieben hab, sonst hätte ich es nicht geschrieben.

Edit:
Naja, sorry - ich bin wirklich überempfindlich. Eiglich bin ich ja froh, dass du ganz genau und richtig verstehst, was ich sage. Und ist eiglich auch logisch, dass du nochmal nachfragst, denn es ist schon recht unerhört, und nirgends anders kriegste die Behauptung serviert, dass Datenbänkerei ohne Sql und ohne Datenbank unvergleichlich viel leichter und schneller zu erlernen ist.
Aber was kann ich dafür? Die Behauptung ist halt wahr, vielfach belegt, und sie ergibt sich auch ganz logisch aus den Möglichkeiten, die typDataset bietet.

---

@HansGlück:
Ich hab jetzt mal eine Schmalspur-Dataset-Adpapter-Variante gecodet, inklusive TopoSort:Anzuwenden so:Bei Fragen fragen, imo sollte dir aber alles so leidlich verständlich sein.
Es ist die MS-Strategie - sieht man ja auch - beim Deleten läuft die Schleife rückwärts

sehr cool vielen Dank, zieh ich mir am kommenden Wochenende rein.

einige fragen bzw gedanken möchte ich vorab (meine tests kann ich erst am samstag starten) noch anhängen die mir gerade durch den kopf gingen:

theoretisch habe ich doch mit diesem schema egtl. auch gleich multiuser mit access abgehakt oder?
zumindest dann wenn ich nach der eingabe der daten nicht nur die bindingsource mit endedit sondern auch gleich die save methode deiner klasse aufrufe.

oder bedenke ich da was nicht? über die reihenfolge macht sich dann ja die access db gedanken oder?
du fragst ja mit @@identity ab wie der prim key heisst?
last in wins wäre dann das ergebnis was ja in ordnung ist, das würde aber auch bedeuten dass beim form aufruf die fillall methode aufgerufen werden muss und nicht nur beim start der anwendung (kann ja durch einen anderen user schon änderungen in der db gegeben haben...).

denkbar wäre dann ja auch eine automatische aktualisierung oder eine art reload button oder sowas.

was meinste?

Bei Multi-User ist immer die Concurrency-Problematik zu lösen.
Anders als beim Abspeichern gibt es dafür keine allgemeingültige Lösung - das ist nichtmal denkbar. Es ist doch ein allgemeines quasi-mathematisches Gesetz (also höher noch als Naturgesetze):
Wann immer mehrere von derselben Ausgangsbasis aus etwas tun, entstehen verschiedene Ergebnis-Versionen.
Ist nur ein Ergebnis zulässig (was bei Datenbanken der Fall ist), entsteht zwangsläufig das Problem, sich zu entscheiden. Es gibt ein paar Standard-Strategien, und je nach Lage ist eine davon (oder auch was ganz proprietäres) anzuwenden.

Das Problem selbst ist wie gesagt universal, das haben Entwickler einer Software im Team ebenso wie Eltern, die sich absprechen müssen, wer die Kinder vom Kindergarten abholt