Announcement

Collapse
No announcement yet.

Paradox, Index, Order by Nur Lesen => ABER WANN ??

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Paradox, Index, Order by Nur Lesen => ABER WANN ??

    Ich verzweifele langsam an Pardadox 7 mit Delphi 5 C/S :
    Ich kann nicht nachvollziehen, wann ich eine editierbare Ergebnismenge
    erhalte. Ich las im Forum schon, das die Order by Felder indiziert sein müssen, aber das reicht NICHT ;-(
    Weiteres Problem : Erzeuge ich einen Index via SQL (Create index ...)
    kann ich ihn nennen wie ich will, auch gleich dem Feldnamen.
    Versuche ich mit der Datenbankoberfläche einen Index zu erzeugen, erscheint
    die Meldung, dass nur Primärindexe genauso wie Feldnamen heissen dürfen.
    Nach meinem Verständniss kann eine Tabelle nur einen Primarykey haben :
    Aber ich glaube hier liege ich auch falsch.
    Das Original-Handbuch habe ich jetzt schon zig-mal durchsucht .. Hinweis
    auf entsprechende Seitenzahlen werden gerne entgegengenommen ;-)
    (Seite 21-18 : Einschränkungen für Abfragen mit aktualisierbaren Ergebnismengen)

    TUpDateSql scheint mir keine geiegneter Ansatz da 2 Memofelder vorhanden sind UND jede Tabelle 44 Felder hat. Das Erzeugen einer entsprechenden
    Modifiy-Anweisung dürfte "mehrere" Zeilen code & Zeit verschleissen :-(

    Zusammengefasst : Wie erhalte ich mich Delphi und Paradox eine editierbare
    Datenmenge bei einer Sortierung auch mit Desc

    Den Tränen nahe

    Stephan

    PS: Requestlive etc. ist bekannt - Bei MANCHEN Sortierungen klappt es ja ;-)

  • #2
    Hallo,

    Paradox ist keine SQL-Datenbank, daher muss die BDE die SQL-Fähigkeit simulieren (Local SQL). Da Paradox eine datensatzorientierte Datenbank ist, stellt <b>TTable</b> den nativen Zugriffsweg für Schreiboperationen zur Verfügung. Die SELECT-Abfrage liefert nur eine Ergebnismenge mit einer frei definierbaren Sichtweise auf die Daten zurück - die Fähigkeit, diese Datenmenge editieren zu können, ist ein "Sahnehäuptchen" obendrauf (denn das sieht der SQL-Standard <b>nicht</b> vor). Aus diesem Grund gibt es die o.g. Einschränkungen.

    Wenn man sein Programm vollständig auf SQL auslegt (Lese/Schreibzugriffe), sollte man konsequenterweise gleich zu einer richtigen SQL-Datenbank (mengenorientierte Datenbank) greifen.

    &gt;Nach meinem Verständniss kann eine Tabelle nur einen Primarykey haben ...

    Das ist korrekt - jede Tabelle kann maximal nur einen Primärschlüssel haben, wobei allerdings diese Schlüssel aus mehreren Spalten zusammengesetzt werden darf.

    &gt;Wie erhalte ich mich Delphi und Paradox eine editierbare <br>
    &gt;Datenmenge bei einer Sortierung auch mit Desc?

    Indem man zum von mir so genannten <i>Microsoft Money</i>-Prinzip greift: Im Formular oben ist ein TDBGrid mit der Ergebnismenge der SELECT-Abfrage (TQuery), wobei das TDBGrid ReadOnly ist. Sobald der Benutzer einen Datensatz ändern will, liest das Programm den Primärschlüsselwert des ausgewählten Datensatzes aus und öffnet eine TTable-Instanz mit einem Filter für diesen Primärschlüsselwert. An dieser TTable hängen TDBEdits etc. im unteren Bereich des Formulars, so dass dort der ausgewählte <b>einzelne</b> Datensatz bearbeitet und via TTable bequem gepostet werden kann. Am Ende kann man dann bei Bedarf die SELECT-Abfrage neu ausführen, damit die Anzeige im oberen TDBGrid mit der Änderung synchron bleibt.
    &#10

    Comment


    • #3
      Hi Herr Kosch,

      danke fuer die rasche Antwort. Einschränkungen sind aus dem von Ihnen genannten Grund OK, was mich nervt, ist das die im Handbuch genannten Voraussetzungen für den Erhalt eine aktualisierbaren Datenmenge nicht hinreichend sind oder zumindest nicht immer.
      Ich hatte gestern Abend die Schanuze voll und bin doch auf TUpdSQL umgestiegen. War eingentlich weniger Aufwand als gedacht :

      <PRE>
      With VUDataModule do
      Begin
      UpdateVUSQL1.modifySQL.Clear;
      UpdateVUSQL1.modifySQL.Add('Update '+VuFile+' Set');
      for i := 1 to VUQuery1.FieldCount - 2 do
      UpdateVUSQL1.modifySQL.Add(VUQuery1.Fields[i].FieldName +' = :'+VUQuery1.Fields[i].FieldName +',');
      UpdateVUSQL1.modifySQL.Add(VUQuery1.Fields [VUQuery1.FieldCount-1].FieldName + ' = :'+VUQuery1.Fields[VUQuery1.FieldCount-1.FieldName);
      UpdateVUSQL1.modifySQL.Add('where VuRecNo = :OLD_VuRecNo');
      end; // with VUDataModule
      </PRE>

      Jetzt fluppt alles, egal mit welcher Sortierung ;-)

      Stepha

      Comment


      • #4
        Hallo,

        &gt;..die im Handbuch genannten Voraussetzungen ..

        das Handbuch muss in diesem Punkt schwammig sein, weil die BDE die UPDATE/INSERT/DELETE-Anweisungen einer editierbaren TQuery-Abfrage erst zur Laufzeit generieren muss. Je nachdem, welchen Aufbau die Tabelle hat und wie die SELECT-Anweisung aussieht, fällt die Entscheidung einmal so oder so aus, da die Borländer nicht alle vom SQL-Standard erlaubten Konstrukte berücksichtigen. Im Zweifeldsfall ist das Teil ReadOnly, denn eine Beschädigung des Datenbestands durch wildlaufende SQLs ist doch wohl schlimmer :-)

        P.S: Auch Microsoft hat dieses prinzipielle Problem erst mit ADO.NET gelöst (das Recordset-Objekt von ADO war zwar deutlicher cleverer als die BDE, aber prinzipiell ebenfalls von diesem Problem betroffen)

        Comment

        Working...
        X