TableAdapterManager funktioniert nicht über DSN .txt

  • VB.NET
  • .NET (FX) 3.0–3.5

Es gibt 12 Antworten in diesem Thema. Der letzte Beitrag () ist von oliver3121.

    TableAdapterManager funktioniert nicht über DSN .txt

    Hallo, bin neu im Forum und quäle mich grade ab eine DSN Verbindung zu einer Datenbank in Visual Studio 2010 prof zum laufen zu bringen.
    Habe auf einem 64-bit Rechner (Win7 ) die 32-bit Variante des Odbc- Treibers für .txt/.csv als Datei-DSN angelegt (Textbasierte Datenbank war nicht meine Idee), über die Routine die Datenquelle generiert, Primärschlüssel gelegt, den Tableadapter konfiguriert, Zielplattform ist x86. Die Daten werden angezeigt (also ist der Treiber richtig eingerichtet), aber lassen sich über TableAdapterManager.UpdateAll(...) einfach nicht speichern. Komme einfach nicht dahinter...
    Schon mal vielen Dank für jeden Hinweis.

    TableAdapterManager kannste vergessen.
    Astronomischer Overhead, und mit OleDb funktioniert er nichtmal.

    Verwende stattdessen Dataset->Db

    Noch besser ist allerdings, zunächst mal überhaupt ohne Datenbank zu entwickeln - mindestens so lange, bis sich das Datenmodell alpha-mäßig bewährt - also bis die Anwendung für den Einzel-Client feature-complete ist.

    Hm, das sieht ja gar nicht gut aus. Das Datenbankmodel (oder die -struktur) ist erst mal nicht so wichtig, da es um die prinzipielle Lösung geht (wie gesagt .txt als Datenquelle war nicht meine Idee). Der Grundgedanke ist, eine Vorlage für Einzelnutzer zu schaffen. Die damit generierten Daten sollen später auf einen Server geladen werden. Es geht also um die Bereitstellung von Rohdaten über eine Anwendung. Einen Stream reader zu benutzen würde vielleicht auch gehen, netter und einfacher wäre natürlich, das Dokument gleich als Tabelle anzusprechen und noch besser sich auf andere Tabellen beziehen zu können.
    Gibt es denn keine Arbeitserfahrungen eine .txt/.csv- basierte DB in VS zu erstellen?

    oliver3121 schrieb:

    wie gesagt .txt als Datenquelle war nicht meine Idee
    Da fällt mir ein: DataAdapter werden nie Text-Dateien als Datenbank updaten können.
    Weil eine Text-Datei hat keinen Primärschlüssel.

    Bzw. man muss gewaltig rum-murksen, besondere Queries anlegen, die eine Spalte dann doch als Primkey auffassen, obwohl sie das nicht ist (woraus sich dann weitere Verwicklungen ergeben).

    Wie dem auch sei:

    oliver3121 schrieb:

    Das Datenbankmodel (oder die -struktur) ist erst mal nicht so wichtig,
    Das ist ein verheerender Irrtum - das Datenmodell ist immer das Fundament einer Anwendung, auch einer Test-Anwendung, und auch bei Prototypen.


    Aber nochmal zur Text-Datenbank: Versuch den Erfinder dieser Idee davon abzubringen. Für eine Datenbank soller eine Datenbank nehmen, sehr lightweight wäre zB SqlCe, sehr einfach zu behandeln ist Access.

    Und entwickel das zunächstmal DatasetOnly, denn sonst verbaust du dir alle Möglichkeiten, eine databinding-getriebene Oberfläche zu entwickeln.

    Hast du das gegebene Tut downloaden und den Code ausführen können - hats funktioniert?

    - die Sache mit dem Primärschlüssel: war auch mein Gedanke, man kann ihn im DataSet zwar festlegen, aber er ist ja eigentlich nicht direkt in der Datei. In der Schema.ini gibt es leider keine Möglichkeit eine Spalte als Key zu kennzeichnen.
    - Modell ist wichtig - klar, aber ich brauche erstmal nur den methodischen Ansatz - und der scheint in diesem Falle irgendwie ins Leere zu laufen
    - SqlCe war schon mein Vorschlag und der Erfinder der .txt- DB ist mein Vorgesetzter, Direktor des Amtes ,leider auch noch promovierter Ingenieur und soll bitte meinen nächsten (und bald fälligen) Zeitvertrag unterschreiben
    - ich probier gleich mal den code aus

    oliver3121 schrieb:

    der Erfinder der .txt- DB ist mein Vorgesetzter, Direktor des Amtes
    Wenner intelligent ist, vermag er auf gute Vorschläge zu hören, und Gut-Vorschläger kriegen dann Pluspunkte.

    Andernfalls... :(

    Ja, das mit dem methodischen Ansatz wird schwierig.
    Ich hab bislang auch immer nur bestenfalls .csv abgerufen mit odbc - nie geupdated oder inserted.

    Ah - was vlt. geht ist System.Guid als Primkey herzunehmen!
    Aber es bleibt ein Gekrepel und eine proprietäre Spezial-Lösung - vmtl. müsste ich dir ein Behavior schreiben, was bei DataTable.NewRow immer einen gültigen Primkey generiert.

    Tja, eigentlich will ich nur hören, dass es nicht geht. Übrigens: wenn ich versuche die Textdatei in OpenOffice (Base) zu laden (und dieses Feature ist dort ausdrücklich vorhanden) funktioniert die Sache ebenfalls nicht. Die Daten werden dargestellt, können aber nicht geändert werden. Vielleicht ist der odbc-Treiber veraltet und die Geschichte funktionierte super unter win95. .csv/oder .txt ist eben ein Austauschformat.

    jo - wie gesagt - ich bin noch nie auf die Idee gekommen, eine csv-"Datenbank" updaten zu wollen.

    Gut möglich, dass das nicht geht, denn normalerweise muss man eine TextDatei komplett neu schreiben, wenn man eine Zeile daraus löschen oder verändern will. Da wäre es logisch, dass ein odbc-treiber das erst garnet unterstützt, denn 3 Updates würde die Datei 3 mal neu schreiben - das wäre Irrwitz.

    vlt. googeln, ob das ühaupt geht...

Facebook
Telefonspende