Hei Community,
seit einigen Wochen lese ich als Gast in diesem Forum. Nun hab ich mich angemeldet, dies ist mein 1.Beitrag, deshalb meine Kurzvorstellung:
Nächstes Jahr werde ich siebzig, seit 1968 programmiere ich in Assembler, COBOL, PL/1 und RPG kommerzielle Lösungen auf Groß- u. Midrange-Systemen, die letzten 25Jahre als selbständiger "Alleinunterhalter". Nun bin ich Rentner. In den 90er Jahren habe ich ein Musik/Video/Zeitschriften-Archiv Verwaltungsprogramm incl. vieler Anzeige-u. Druckmöglichen mit CLIPPER / dbase erstellt. Leider sind diese Programme unter WIN7/64Bit nicht mehr lauffähig. Alle Virtualisierungen gefallen mir nicht, darum möchte ich die Anwendung (Einzelplatzsystem, nur mich mich) jetzt in VB neu schreiben.
In der Musikdatei z.B. sind über 15000 Musiktitel mit Interpret, Erscheinungsjahr, Laufzeit, Typ (LP,CD etc) Archiv-Nr usw gespeichert, die will ich nicht nochmal neuerfassen, aber ich möchte meinen Erben eine brauchbare Dokumentation hinterlassen.
Nun zu Visual Basic. Installiert hab ich Visual Studio Express 2013, kein Access, keine DB.
Habe mir Lehrmaterial gekauft, zig Tutorials angeschaut, hier im Forum stundenlang gelesen und muß feststellen: es ist eine andere Welt!
Die Benutzeroberfläche/Menüstruktur hab ich fast fertig, das ging komfortable und hat Lust auf mehr gemacht.
Nun meine Frage:
wie verarbeite ich die alte .dbf-Datei (feste Satzlänge, feste Feldlängen) ?
Wie, womit erstelle ich Zugriffswege (logische Sichtweisen z.B. nach Titel oder Interpret, für die spez. Auswertungen ?
Kann man die Datei in VB auch rückwärts lesen? Sind Teilschlüssel zum Aufsetzen vor dem Lesen möglich?

Bisher hab ich entweder DB-Ansätze oder simple .txt-Datei Bearbeitungen gesehen.
Das ich die OOP und VB nicht mehr in allen Tiefen erlernen werde, ist mir schon klar. Aber vielleicht lerne ich ja hier einen VB-Genossen aus meinem Wohnumfeld kennen der mir verbale, persönliche Hilfestellung geben kann. Ein vernünftiges, reales Beispiel ( keine Spieldaten, nicht als Konstanten im Programm erstellt) würde mich ja schon auf die Spur bringen. Ich will keinen Code abschreiben, ich möchte die Syntax wörtlich (MSDN ist für den der es kann als Bestätigung seiner Fähigkeiten geschaffen, lernen kann ich damit nur schwerlich) Stück für Stück erklärt haben.
Ja ich weiß, viel verlangt. Versucht's trotzdem mal mit mir.
Ist ja kein Terminprojekt. Jetzt fahr ich sowieso erstmal ne Runde mit meinem Mopped. Die Sonne lacht.

Gruß aus GT
von Knut

Wegen der DB: stackoverflow.com/questions/22…bf-files-into-a-datatable C# lässt sich mithilfe von Onlineconvertern ziemlich fehlerfrei in VB.NET übersetzen und zu C# gibts halt einfach mehr Erklärungen mit durchschnittlich besserer Qualität.

Wegen dem Lernen von VB: Allgemein würd ich Anfängern empfehlen, erstmal simplen und qualitativ guten Code zu lesen und zu verstehen. Dann kann man später immer schön die richtigen Sachen mit IntelliSense oder mit googeln herausfinden. Wenn dir das nicht passt, kannst du natürlich auch versuchen, es dir erklären zu lassen, da hat aber leider nicht jeder Lust und Zeit dafür.

SideCarDriver schrieb:

wie verarbeite ich die alte .dbf-Datei (feste Satzlänge, feste Feldlängen) ?

Hallo Knut,
mit der alten .dbf Datei würde ich nicht weiter arbeiten.
Konvertiere Diese doch einfach in ein aktuelles DB-Format.
Falls Dein Programm eine Einzelplatzanwendung ist, würde SQLite oder MDB vollkommen reichen und setzt keinen Server voraus.
Wenn Du nicht weißt, wie Du sie am besten wandeln kannst, sag Bescheid.

ich weiß garnet, obs für vbnet ühaupt noch Zugriffsmöglichkeiten auf eine Clipper-Datei gibt.
Zur Not müsteste mit deim alten Proggie einen Export in eine Text-Datei machen, und dann in vb.net einen Import schreiben, der die TextDatei schön einliest in ein typisiertes Dataset.

Hurrah! typDataset, mein LieblingsThema!
Ich schockier die Leuts ja immer, indem ich empfehle, ohne Db zu entwickeln.
Ado.Net hat tolle Unterstützung für die Entwicklung, aber das Thema ist auch eine ziemliche Menge zu lernen. Und wenn man da gleich mit Datenbank aufsetzen und kommunizieren anfängt, verbaut man sich 90% der og. tollen Unterstützung, wird sie nie ühaupt kennenlernen, und proggt eiglich zwangsläufig monströse, unwartbare Ungetüme.
Aber lies doch die Vorbemerkung von Daten laden und speichern
Jo, und gugge vier Views-Videos, für einen Vorgeschmack, wie komfortabel das Entwickeln sein kann, wenn man die ganzen Fußfallen zu betreten sich zu enthalten weiß.
Letzteres Tut mag dich aber als Neuling in vielen Punkten überfordern - in dem Tut fließt halt alles zusammen, was man drauf haben muss, um eine ordentliche Datenverarbeitung hinzuhauen.

Im Einzelnen hab ich das notwendige KnowHow mal hier zusammengestellt: Datenverarbeitungs-Vorraussetzungen.
Mit weniger gehts leider nicht, sonst treten unausweichlich früher oder später unlösbar erscheinende Probleme auf (welche natürlich mit Leichtigkeit lösbar sind, wenn man weiß wie, und deshalb ja diese Sammlung ).

Wie schon erwähnt würde ich auch auf die Benutzung der alten DBF's verzichten (für Delphi gibts Absolute Database, das kann mit solchen Dingern noch umgehen - keine Ahnung, was man da in .NET nehmen kann).

Ich würde einen anderen Weg gehen. Die Daten im XML-Format vorzuhalten wäre sicherlich erstmal ein gangbarer Weg und ist auch relativ einfach gemacht (Serializer/Deserializer). Auch wenn mir jetzt gleich ein Sturm der Entrüstung ins Gesicht pustet Aber für den Anfang sollte das genügen.

Doch wie bekommt man die ins XML-Format ? Da du einen beträchtlichen Datenbestand da liegen hast, würde ich übers konvertieren nachdenken. Noch einmal kurz das gute alte Clipper-Wissen hervorkramen und die DBFs Datei für Datei z.B. nach CSV konvertieren. Clipper kann doch Textdateien schreiben ? (Ist zu lange her, das ich damit zu tun hatte).

Diese CSV-Dateien kann man dann mittels eines Importers dann in die gewünschten XML-Dateien umwandeln und damit arbeiten. Ich sage dir schon jetzt, das du mit den Umlauten Ärger haben wirst (DOS-Codepage 437 gegen Windows-1252), aber das sind alles beherrschbare Probleme.

Klingt umständlich, hat aber einen Sinn: Mehr Sicherheit in der neuen Welt erlangen. Über "richtige" Datenbanken wie Access oder SQL-Server Compact reden wir dann später. Erstmal wollen wir die Daten rüberretten, der Rest ist dann "Candy".

Ich hoffe, wenn ich demnächst 70 werde (so in ~25 Jahren), noch ebenso fit inner Birne zu sein wie der TE.

Hallo @OlafSt,

Microsoft hat an Dich gedacht:

Herstellen einer Verbindung mit einer dBASE- oder einer anderen DBF-Datei

Vom SQL Server kannst Du dann leicht in ein beliebiges Format konvertieren:

Database-Generator

Clipper war seinerzeit auch mein Tool der Wahl, um dBaseIII schneller und programmierbarer zu machen.
Wegen des überwiegend prozeduralen Ansatzes ist jedoch eine Konvertierung nach meiner Auffassung nicht sinnvoll.
Tauch' ein in die (Un)tiefen von vb .net - und schau Dir diverse videos vom @ErfinderDesRades hier im Forum an, das gibt den richtigen Einstieg.

Hallo VB-Gemeinde,

schön dass ihr euch mit meinem Problem beschäftigt habt. Danke dafür.
Meine Erkenntnis: es gibt also doch Wege.

@ nafets: dein Hinweis ist bestimmt für C# gedacht, ich möchte das aber in VB machen
@ simplSoft: danke für deine Hilfsanbietung, ich komm bestimmt darauf zurück, wenn ich mir selber über meine
Vorgehensweise klar bin.
@ErfinderDesRades: das hört sich alles vielversprechend an. Die "vier Views" , "Daten laden u. speichern" schau ich mir gerne zum 9.mal an, aber der Ton ist sehr mager, deine Denkweise und Benamsungen erfordern momentan von mir mehr Aufmerksamkeit als das eigentliche Thema. Ich weiß wie schwer es ist solch eine allg.gültige, verständliche Doku zu machen,
aber mir sind die Beispiel noch zu theoretisch. Trotzdem danke u. dickes Lob für diese Arbeit.
Heißt es jetzt eigentlich "typisiertes" oder typerisiertes DataSet? Kann ich ein typ. DataSet als Sieb, als Umformer, als Verbinder zur Datei verstehen? Und muß bei jedem früheren Lese/Schreib/Update-Befehl das DataSet im Spiel sein, oder wird einmalig die vorhandene Datei durch dieses DataSet gejagd? Ich mach mal ein kleines TestPgm mit dieser Technik.
@olafSt / @us4711: in diese Richtung denke ich im Moment weiter, danke. Ein echter Dateizugriff ohne den Umweg über ein
DataSet (wobei ich noch nicht genau weiß was das eigentlich wie macht) käme meiner Programmstruktur schon näher.

Also: Ich bleib am Ball und denke bald konkretere Fragen stellen zu können. Im Moment muss ich erstmal lernen, wie hier z.B. zitiert wird und mir die Nutzung des Forums zu eigen machen.

Grüße aus GT - Knut

SideCarDriver schrieb:

dein Hinweis ist bestimmt für C# gedacht, ich möchte das aber in VB machen

Schau dir meinen nächsten Satz an:

nafets schrieb:

C# lässt sich mithilfe von Onlineconvertern ziemlich fehlerfrei in VB.NET übersetzen

Also, nimm den Code von meinem Link und kopier ihn hier rein, klick auf Convert to VB.NET, und nimm das Ergebnis. Es mag vielleicht etwas komisch klingen, Code zwischen Programmiersprachen hin und her zu konvertieren, bei .NET-basierten Programmiersprachen (wie VB.NET und C#) ist das kein Problem, da die meisten Sachen in beiden Programmiersprachen gleich sind.

SideCarDriver schrieb:

aber mir sind die Beispiel noch zu theoretisch.

Hu?
Also praktischer kann ichs nicht machen. Dir ist schon aufgefallen, dass du den SourceCode downloaden kannst und in deinem Visualstudio dann kompilieren und ausführen?

SideCarDriver schrieb:

Heißt es jetzt eigentlich "typisiertes" oder typerisiertes DataSet?

typisiertes Dataset

SideCarDriver schrieb:

Kann ich ein typ. DataSet als Sieb, als Umformer, als Verbinder zur Datei verstehen?

Es ist ein Cache.
Dahinein lädtst du die Daten, und da drinnen kannst du sie verändern.
Oder du bindest halt Controls da dran, dann verändert der User die Daten gewissermaßen direkt.
Anschließend kannst du die Daten zurückspeichern.

nafets schrieb:

Also, nimm den Code von meinem Link und kopier ihn hier rein, klick auf Convert to VB.NET, und nimm das Ergebnis

hab ich gemacht, aber ich sehe kein Ergebnis - wo sollte das dann stehen?

Ich hab da keine Probleme - ich schreib den VB-Code einfach mal hier rein:

Ein Dataset ist nix weiter als ein Zwischenlayer zwischen der Datenbank und "dir". In Clipper/dBase gibt es sowas nicht, da hängst du direkt am Datenbank-File. Das Dataset schiebt sich dazwischen, koppelt dich also von der DB-Datei ab.

Was zuerst als Nachteil klingt, offenbart sich sehr schnell als Vorteil, weil es dir dank des Datasets völlig schnuppe sein kann, was für eine Art von Datenbank-Datei du da vorliegen hast. Ob nun dBaseIV, XML, SQL-Server Compact oder ein 64-CPU-dual-load-balanced SuperCluster mit Oracle drauf: Kann dir egal sein, du redest immer auf dieselbe Art mit dem Dataset - und das Dataset kümmert sich darum, wie das ganze in die/aus der tatsächlichen DB kommt.

@nafets: danke, das zieh ich mir mal in Ruhe rein

@ErfinderDesRades:

ErfinderDesRades schrieb:

Also praktischer kann ichs nicht machen. Dir ist schon aufgefallen, dass du den SourceCode downloaden kannst und in deinem Visualstudio dann kompilieren und ausführen?

doch: Category = Warengruppe (Anzüge,Hosen,E-Geräte,Uhren,Unterwäsche)
Article = Artikel (Jeanshose 4711, Kaffeemaschine Melissa, Rolland-Herren Uhr Silber)
Deliverer = Lieferant (Meier OHG, Franz u. Söhne, Hexa-Meister KG)
aber egal, daß macht die Sache nicht viel einfacher. Verstanden hab ich das schon seit Jahren, war in DB2, DB400, VTAM etc nicht anders.
Interessant wäre zu sehen wie und wo die Datenquellen ARTICLE etc herkommen, wo sie gespeichert sind, kann man da denn z.B. dann eine Feldgröße und den Typ (Char, Integer, etc) sehen ?
Das ich den SourceCode herunterladen kann und dann umwandeln weiß ich, nur weiß ich (noch) nicht wie.

Ein Datenmodell kann ich gar nicht aufbauen, weil ich ja nur eine Datei (Musik.dbf egal wie die später mal heißt) habe und somit auch keine Beziehungen herstellen kann oder brauche.

Aber: mein VisualStudio sieht ganz anders aus als bei dir. Oben die Schaltfläche DATEN gibt es bei mir gar nicht, da steht nach DEBUGGEN, TEAM, sofort EXTRAS.

Und wenn ich die Fragen von PETER329 bzgl. Dataset lese, wird mir auch nicht wohler. In deiner Antwort zu PETER329-Fragen
wird ja deine eigene Euphorie-Welle zu Dataset's auch etwas flacher.

Trotzdem ein großes DANKE, dass ich mich hier austauschen und letztlich auch schlaumachen darf. Im Moment (gerade wenn ich die großen Schwierigkeiten beim Erstellen einer simplen Druckausgabe sehe, (unbekannte Anzahl von A4-Seiten mit Überschrift und formatiertem Text und unterschiedlichen Schriftgrößen in einer Zeile muß ich mal drucken)) ist VB vielleicht doch nicht das richtige Werkzeug.

@OlafSt: danke, nun ist es klarer für mich

Knut

Wenn es ums Drucken geht, wären glaub ich Reports ne gute Sache. und in anderen Sprachen wird das Problem glaub ich auch nicht wirklich einfacher zu lösen sein...

SideCarDriver schrieb:

kann man da denn z.B. dann eine Feldgröße und den Typ (Char, Integer, etc) sehen ?

Selbstverständlich, das wird doch bereits in Film1 gezeigt: Nämlich im DatasetDesigner, im PropertyFenster.
Da stelle ich ein, dass Article.Name String ist, und Article.ID ist Int32.

Die Videos sind ziemlich konzentriert: je neuer das dir ist, desto öfter musstes wohl durchmachen, bzw. am Besten sogar selbst durchspielen.

SideCarDriver schrieb:

Ein Datenmodell kann ich gar nicht aufbauen, weil ich ja nur eine Datei (Musik.dbf egal wie die später mal heißt) habe und somit auch keine Beziehungen herstellen kann oder brauche.

Dann hast du Datenmodellierungs-Fehler, schon immer gehabt.
Selbstverständlich muss eine MusikBibliothek-Datenbank Tabellen haben für Interpreten, Alben, Tracks, etc, und diese Tabellen stehen miteinander in Beziehung.
Alle diese Tabellen sind in einer einzigen Datenbank-Datei, ja, oder - wie ich es empfehle - in einer einzigen Xml-Datei, aus der Das Dataset direkt eingelesen wird.
Die Xml-Datei speichert man übrigens einfach mit Dataset.WriteXml ab.

SideCarDriver schrieb:

Aber: mein VisualStudio sieht ganz anders aus als bei dir. Oben die Schaltfläche DATEN gibt es bei mir gar nicht, da steht nach DEBUGGEN, TEAM, sofort EXTRAS.

Ja, das ist ein Problem, ein leidiges.
MS hat es gefallen, ab 2012 das VisualStudio-Design gründlich zu verwüsten, alle Farben zu ändern (vorzugsweise in verschiedene Graustufen), alle Knöppe iwo annershin zu verlegen, und was anneres draufzuschreiben.
Ach und natürlich auch die Tastenkürzel alle mal feste umrühren!

Also da musste nun herumsuchen, dass du die inne Videos gezeigten Knöppe bei dir wiederfindest - glaub mir: wirklich weggeschmissen haben sie keinen (hurra! )

@ nafets: noch bin ich ja nicht beim Drucken angelangt, aber bisher habe wenig Tut's oder Erklärungen über die
Druckausgabe in VB gefunden.

@ErfinderDesRades: okay, ich suche dann mal die Knöppe in meiner VS-Version

Aber schau doch mal ein Bild meiner Datei. Das ist alles um was es geht - allerdings ca. 15000 Sätze.
Natürlich hätte ich im Profi-Bereich eine Stammdaten-Datei für z.b. Interpreten angelegt, aber hier nur für mich allein hat meine Tochter die PC-Tastatur ausgiebig kennengelernt. Hat auch was gutes.

Das grenzt ja an Kindesmisshandlung
Ich habs Datenfenster jetzt übrigens gefunden: Menu-Ansicht-weitere Fenster-Datenquellen

ErfinderDesRades schrieb:

Ich habs Datenfenster jetzt übrigens gefunden: Menu-Ansicht-weitere Fenster-Datenquellen

danke, dann schau ich mal

@ErfinderDesRades, @SideCarDriver
Kennt ihr schon die Schnellstart-Funktion (Strg + Q) im neuen VS? Einfach dort nen Suchbegriff (zum Beispiel "Daten") eingeben und es zeigt sofort den Menüeintrag für das Datenquellen-Fenster an. Kein mühsames Durchforsten der Menüs nötig.