Hallo, kann mir jemand in Kurzform mitteilen, ob es bei der Progammierung von Daten-Dateien (Access/Excell o.ä.) Dateibeschreibungen geben muss, ähnlich FDF's in Cobol.
Ich konnte bei Schnelldurchsicht einer Visual-Basic-Programmieranleitung nichts finden.
Danke für Tipps.
Programmieren - alles kontrollieren 4.941 Themen, 20.708 Beiträge
Erklär mir doch mal was FDF's sind.
Dann sag ich dir obs irgenwas ähnliches in VB VBA .NET und Co gibt.
Hallo Paolo, FDF's war und ist die Abkürzung in der Programmierung bei Cobol, Assembler, RPG usw. und steht für
File Description File, was wiederum eine Dateistruktur darstellt.
z.B. Dateiname
Feldname1(Länge,Art,evtl. Nachkommastellen,
Feldname2( dto ) usw.
ggfls. mit Unterstrukturen.
Gruss mthr
Hallo!
> Dateibeschreibungen geben muss
Extra Datenbeschreibungen sind nicht zwingend erforderlich.
in Access z.B. kannst Du eine Tabellendefinition direkt im Programm
vornehmen. Vielleicht bringt diese Seite etwas Erleuchtung:
http://www.schmittis-page.de/index.html?/excel/vba/t42.htm
Cobol, RPG, Assembler - lange nichts mehr programmiert?
Gruss
ChrE
Hallo ChrE, stimmt - mehr als 20 Jahre.
Habe jetzt aber wieder Lust darauf bekommen und taste mich langsam vorran.
Vielen Dank für die Tipps.
Gruss mthr
Hallo!
> Habe jetzt aber wieder Lust darauf bekommen und taste mich langsam vorran.
Na dann soll gerechterweise auch dieses Beispiel nicht fehlen:
http://docs.python.org/library/sqlite3.html
Auch wenn es nix mit VBA zu tun hat.
Gruss
ChrE
Du willst eine leere Datei eines bestimmten Typs erstellen in dem Fall Excel oder Access
wenn ich es richtig verstanden haben. In dem Fall musst du das entsprechende Programm
bemühen. Auf DAO wie auf der LinkPage von ChrE würde ich persönlich aber verzichten
und das Excel oder Access COM Object Model verwenden.
Danke PaoloP, werde entsprechend sichten.
Gruss mthr
das erstellen einer leeren excel datei sieht in etwa so aus.
Private Sub BlaBlub()
Dim objexcel ' As Excel.Application
Set objExcel = Createobject("Excel.Application")
objexcel.Workbooks.add
objexcel.ActiveWorkbook.SaveAs "C:\test.xls"
objexcel.Quit
Set objexcel = Nothing
End Sub
Ich hoffe du meinst VB6 da mit "VB" inzwischen genauso synonym auch VB.NET gemeint wird.
Danke nochmals PaoloP.
Gruss mthr
Hallo,
@mthr:
Borlander hat recht.
Vielleicht solltest Du, bevor Du anfängst zu programmieren,
noch mal die Begriffe DAO, ADO und .NET klären.
.NET wäre wohl z.Z. das "Angesagteste".
Gruss
ChrE
Ich hoffe nicht. Es scheint mit wenig zweckmäßig auf eine Sprache zu setzen deren IDE nicht mehr supported wird und deren Nachfolgetechnologie inkompatibel ist...
COBOL hat mehr Zunkunft als VB6.
Hallo Borlander, kann ich das so verstehen, dass meine ergrauten Cobol-Kenntnisse noch verwertbar sind ?
Gruss mthr
Hallo,
Gute Cobol-Programmierer werden in GOLD aufgewogen.
http://www.cobol-day.de/
http://www.heise.de/ix/news/foren/S-COBOL-programmieren-ist-fast-wie-Gedichte-schreiben/forum-168176/msg-17560442/read/
Gruss
ChrE
Hallo ChrE, Deine Aussage überrascht mich - ich bin schon seit vielen Jahren aus diesem Geschäft raus, mich hat es aber trotzdem interessiert, ob auf dieser Basis noch Programme erstellt werden.
Jetzt, nach Ausscheiden aus dem Berufslebens wäre es vermessen zu glauben, dass ich auf dieser Ebene noch etwas aufbauen könnte. Im Übrigen will ich das auch gar nicht, mir waren nur die Verhältnisse zwischen der damaligen EDV-Konstellation und den heutigen Resourcen irgendwie nicht ganz vorstellbar.
In unserem Grosshandelsunternehmen hatten wir als Ausstattung eine Nixorf-8870-Anlage.
An dieser hingen ca. 10 - 12 Bildschirme, Hauptspeicher war mit 128 KB, als Plattenspeicher dienten 2 x 6 Mio.-Byte-Laufwerke.
Es wurde im Double-Progr.-Verfahren auf der einen Ebene die gesamte Auftragsverwaltung>Lagerbestandsverwaltung>Fakturierung>Kontokorrentverarbeitung durchgeführt, über die zweite liefen dann parallel die Verarbeitungsprogramme.
Aber ich will nicht länger langweilen, das Ganze spielte Mitte der 70 er Jahre.
Gruss mthr
Da wo ich herkomme sind VB6 Kentnisse ein notwendiges Einstellungskriterium
im Gegensatz zu Cobol. Das hoffe bezog sich im Prinzip nur auf die Verwendbarkeit des Beispielcodes da er sonst mit dem nix anfangen ann.
Hallo,
> mich hat es aber trotzdem interessiert, ob auf dieser Basis noch Programme erstellt werden.
Erstellt wohl nicht mehr so viel - es geht eher um die
Wartung vorhandener Programme und um Datenkonvertierung und Anpassung
von Interfacen.
Es gibt halt noch viel Cobol-Code und vor allem Banken sind froh,
wenn sich noch jemand damit auskennt.
> Verhältnisse zwischen der damaligen EDV-Konstellation und den heutigen Resourcen irgendwie nicht ganz vorstellbar.
Doch, doch, habe selber an einem PDP-11 Clone (K 1630) mit Fortran IV gerbeitet.
Gruss
ChrE