Probleme beim TTable sortieren

[JHOF]

Hallo,
ich versuche eine Tabelle in einer Access-Datenbank zu sortieren (in einer TADOTable (nennen wir sie DBT) dargestellt) und zwar nach einem Long Integer Feld in der Access-Tabelle ( nennen wir es 'AF'; das Feld ist indiziert):
if (DBT.Active = True) then DBT.Close;
DBT.IndexFieldNames := 'AF';
DBT.Open;
Wenn ich das so mache, bekomme ich beim Ausführen des DBT.Open die Nachricht: "Die Argumente sind vom falschen Typ, liegen außerhalb des Gültigkeitsbereiches oder sind miteinander unvereinbar".
Ich habe das genau so in der Steinzeit mit Delphi 5 genau so gemacht und das funktionierte. Was mache ich falsch bzw. was hat sich geändert? Ich würde jetzt ungerne mit SQL anfangen und das Ganze über eine Query realisieren. Es müsste ja wohl auch noch so (oder ähnlich) gehen?
Übrigens: kann man auch ein double Feld nach der Größe der Zahlen sortieren? Wenn ja wie?
Schon jetzt vielen Dank von einem Gelegenheitsprogrammierer.

[DeddyH]

Ich hab da zwar nicht wirklich Ahnung von (SQL-"geschädigt"), aber in der Hilfe steht:

Zitat:

Um mit IndexFieldNames eine Sortierreihenfolge des Recordsets einzurichten, muss das Recordset über einen client-seitigen Cursor geöffnet worden sein (die Eigenschaft CursorLocation der Datenmengenkomponente muss auf clUseClient gesetzt sein). Wenn versucht wird, IndexFieldNames mit server-seitigen Cursorn zu verwenden, wird eine Exception ausgelöst.

Könnte es daran liegen?

[Sir Rufo]

Bist du dir sicher, dass du ADO verwendest?

TTable gehört zum BDE Geraffel
TADOTable gehört zu ADO

BTW: Access Version neueste :roll:

[JHOF]

Vielen Dank für den Hinweis, aber die CursorLocation der Datenmengenkomponente ist auf "clUseClient" gesetzt.

[JHOF]

Sorry, TADOTable ist natürlich richtig und so verwendet.

[haentschman]

Hallo...

Zitat:

Ich habe das genau so in der Steinzeit mit Delphi 5 genau so gemacht und das funktionierte.

...entschuldige, aber bei dir sind mit ADO Table gerade mal die ersten Dino´s ausgestorben. :roll:
Vieleicht investierst du deine kostbare Zeit besser um den Umgang mit aktuellen DBMS und SQL zu erlernen.

...auch dabei können wir dir behilflich sein. :thumb:

[nahpets]

Du willst ja einen bereits vorhandenen Index nutzen und das geht über IndexName.

Delphi-Quellcode:

if DBT.Active then DBT.Close;
DBT.IndexName := 'AF';
DBT.Open;

Schließen und Öffnen sollten eigentlich nicht erforderlich sein.

Delphi-Quellcode:

  DBT.IndexName := 'AF';
  DBT.First;

sollte beim neu gesetzten Index den Datensatzzeiger auf den ersten Satz setzen, andernfalls bleibt der Datensatzzeiger unverändert.

[Bernhard Geyer]

Zitat:

Zitat von JHOF (Beitrag 1222074)

Vielen Dank für den Hinweis, aber die CursorLocation der Datenmengenkomponente ist auf "clUseClient" gesetzt.

Bei Access nimmt man clUseServer. Da die Access-DLL's eh im eigenen Adressraum laufen wäre clUseClient nur eine Stupides kopieren der Daten von einer in Access-Verwalteten Pointer in einen per COM/OLE DB-Verwalteten Pointer.

[JHOF]

Nette Antworten, leider lösen sie nicht mein Problem.
Meine Frage war, was am Code falsch ist. Da helfen mir Hinweise auf SQL nicht. Damit kann ich durchaus umgehen, aber ich habe ein altes Programm, das ich auf die Schnelle wieder zum Laufen bringen muss, um es an den wirklich wichtigen Stellen zu verändern. Ich will keinesweg das Programm in Gänze umschreiben. Übrigens: die einzig sinnvolle Antwort auf ein Problem, ist die Antwort, die das Problem löst!

[nahpets]

Hast Du denn IndexName schon ausprobiert, so wie ich schrieb? Und wenn ja, was funktioniert nicht? Welche Fehlermeldung erscheint?

In einem korrekt funktionierenden Programm von mir nutze ich dieses:

Delphi-Quellcode:

procedure TfmMain.dbGridTitleClick(Column: TColumn);
begin
  try
    case Column.Field.FieldNo of
      1 : tb.IndexFieldNames := 'sender,datum,zeit';
      2 : tb.IndexFieldNames := 'zeit,datum,sender';
      3 : tb.IndexFieldNames := 'datum,zeit,sender';
      4 : tb.IndexFieldNames := 'sendung,sender,datum,zeit';
      5 : tb.IndexFieldNames := 'kategorie,datum,zeit,sender';
      6 : tb.IndexFieldNames := 'beschreibung,sender,datum,zeit';
      7 : tb.IndexFieldNames := 'id';
    else
      tb.IndexFieldNames := 'sender,datum,zeit';
    end;
  except
    on e : exception do ShowMessage(e.Message);
  end;
end;

tb = TAdoTable

In diesem Fall müssen bei IndexFieldNames die Felder durch Komma getrennt angegeben werden, nach denen sortiert werden soll. Da ich das immer problemlos bei geöffneter Tabelle mache, könntest Du ja eventuell mal das Schließen der Tabelle weglassen. Es ist halt überflüssig und kostet nur Zeit.

Die Hilfe zu Delphi schreibt hierzu:

Zitat:

Die Eigenschaft IndexFieldNames listet die Felder auf, die als Index verwendet werden sollen.

Delphi-Syntax:

property IndexFieldNames: string;

C++ Syntax:

__property AnsiString IndexFieldNames = {read=GetIndexFieldNames, write=SetIndexFieldNames}

Beschreibung

Verwenden Sie IndexFieldNames als alternative Methode zum Festlegen des Index für eine Client-Datenmenge. Geben Sie den Namen jedes Feldes an, nach dem die Datenmenge indexiert werden soll. Die einzelnen Namen werden durch ein Semikolon getrennt. Die Reihenfolge der Feldnamen wird im Index berücksichtigt.

Mit IndexFieldNames hinzugefügte Indizes unterstützen keine Gruppierungen oder gewarteten Aggregate.
Tipp: Mit IndexFieldNames können Sie zur Laufzeit Sortierreihenfolgen erstellen.
Hinweis: Die Eigenschaften IndexFieldNames und IndexName schließen sich gegenseitig aus. Durch Einstellen der einen Eigenschaft wird die andere zurückgesetzt.

sowie

Zitat:

Die Eigenschaft IndexName bezeichnet einen Index der Client-Datenmenge.

Delphi-Syntax:

property IndexName: string;

C++ Syntax:

__property AnsiString IndexName = {read=GetIndexName, write=SetIndexName};

Beschreibung

Mit IndexName können Sie einen anderen Index für eine Client-Datenmenge angeben. Wenn die Eigenschaft keinen Wert enthält, basiert die Sortierfolge der Datenmenge auf der Eigenschaft IndexFieldNames oder der Standardsortierung im Datenpaket. Die Standardsortierung richtet sich nach dem vordefinierten Index (DEFAULT_ORDER).

Enthält IndexName einen gültigen Indexnamen, werden die Datensätze basierend auf diesem Index sortiert.

Hinweis: IndexFieldNames und IndexName schließen sich gegenseitig aus. Durch Einstellen der einen Eigenschaft wird die andere zurückgesetzt.

Zitat:

Übrigens: kann man auch ein double Feld nach der Größe der Zahlen sortieren? Wenn ja wie?

Indem man 'nen Index drauf legt und den Namen des Index bei IndexName angibt.

PS:

Fehlermeldungen der ADO-Schnittstelle sind nicht immer zwingend aussagefähig und geben nicht zwingend einen Hinweis auf den tatsächlich aufgetretenen Fehler und der tritt meist nicht dort auf, wo die Ausnahme geworfen wird. ( <-- sakastisch formulierte Praxiserfahrung)

Also folgendes Versuchen:

Umsteigen auf IndexName und dort den Namen des zu nutzenden Index angeben.
Zuerst ohne vorheriges Schließen und anschließendes Öffnen der Tabelle. Nur wenn es dann nicht geht mit Close und Open arbeiten.

Geht's damit nicht, was passiert, wenn nur ein Close und ein Open aufeinander folgen, ohne das Setzen des Index?

Geht das alles nicht, dann auf IndexFieldNames ausweichen. Schreibweise der Feldnamen eventuell so, wie in der Datenbank, also Groß-/Kleinschreibung beachten (auch wenn's meiner Meinung nach irrelevant sein sollte).

IndexFieldNames zuerst bei geöffneter Tabelle setzen, nur wenn das scheitert, mit Schließen und Öffnen probieren.

Ist die TAdoTable über eine TDataSource mit irgendwelchen Komponenten zur Anzeige... verbunden? Wenn ja, diese Verbindung probeweise entfernen und erneut probieren.

Der Fehler "Die Argumente sind vom falschen Typ, liegen außerhalb des Gültigkeitsbereiches oder sind miteinander unvereinbar" deutet etwas globalgalaktisch auf ein dateninduziertes Problem hin, der Fehler muss letztlich nicht zwingend in Deinen drei Zeilen Quelltext liegen, sondern kann überall dort auftreten, wo beim Öffnen oder Scrollen (was beim Öffnen automatisch passiert) etwas mit den Daten (z. B. das Anzeigen) geschieht. Ggfls. auch mal alle Ereignisroutinen der TADOTable (im Objektinspektor) entfernen, sofern vorhanden.

Läßt sich die Tabelle im Objektinspektor öffnen? Wenn ja, im Objektinspektor mal IndexName bzw. IndexFieldNames wie gewünscht befüllen. Klappt das dort?

[JHOF]

Lieber Nahpets,
vielen Dank für den ausführlichen Beitrag, der sehr hilfreich ist. Allersding lag der Fehler wie so oft im Detail: die Accesstabelle lässt als Feldnamen auch Bezeichnungen zu, in denen Blanks vorkommen, also z.B. 'Guten Tag'. Delphi kann damit zurecht kommen, zumindest wenn man den Feldnamen in der Form benutzt wie z.B. in ADT.FieldByName('Guten Tag').AsInteger. Sobald man das Feld aber indiziert um zu sortieren, geht es in die Hose. Da funktioniert nur 'GutenTag'. Muss man erst mal rausfinden.
Aber trotzdem vielen Dank für deine Antwort, die sich wohltuend von einigen anderen abhebt, die für den Gelegenheitsprogrammierer wenig hilfreich sind.

[nahpets]

Ohja, Leerzeichen in Tabellennamen und/oder Spaltennamen, da habe ich auch schon Stunden gesucht. Wer sowas macht, gehört verhauen ;-)
Und die Fehlermeldung deutete ja auch sehr präzise darauf hin :-(

[nahpets]

Ach, da fällt mir noch was ein:

Leerzeichen im Indexnamen könnten unter Umständen eventuell vielleicht man weißnicht so genau mit QuotedStr funktuionieren:

Delphi-Quellcode:

dbf.IndexName := QuotedStr('Guten Tag');

Hab's noch nicht ausprobiert, aber eventuell geht's ja.

[p80286]

Da Access ja ein wenig eigenwillig ist könnte man ja es auch einmal hiermit versuchen
[Tabellenname].[Feldname]
ggf. muß zusätzlich mit doppelten Anführungszeichen gearbeitet werden.
Gruß
K-H

[Furtbichler]

Zitat:

Zitat von JHOF (Beitrag 1222092)

Dank für deine Antwort, die sich wohltuend von einigen anderen abhebt, die für den Gelegenheitsprogrammierer wenig hilfreich sind.

Lieber JHOF, so wohltuend und richtig deine Kritik an dem Antwortverhalten ist, so sehr vermisse ich bei deiner Problembeschreibung die Feldbezeichnung 'Guten Tag', also mit Leerzeichen. Bei dem Feldnamen 'AF' kommt man von selbst einfach nicht drauf.

Also: So wichtig eine problemorientierte Antwort ist, so wichtig ist mindestens eine antwortorientierte Problembeschreibung. :-D

[Bernhard Geyer]

Zitat:

Zitat von Furtbichler (Beitrag 1222113)

Also: So wichtig eine problemorientierte Antwort ist, so wichtig ist mindestens eine antwortorientierte Problembeschreibung. :-D

:thumb: FULL ACK.

Wenn man immer im voraus wüsste das der Fragestelle ein Tunnelblick hat und Hinweise auf Probleme die Rechts und Links neben seinen aktuellen Problem lauern ignoriert würde ich mir meine Zeit die ich kostenlos zur Verfügung sparen und solche Fragesteller liebend gerne ignorieren.

Glücklicherweise gibt's auch genügen Fragestelle die Hinweise auf andere vorhandene Probleme/Schlechte Implementierung die sich mit der gestellten Frage zeigen gerne annehmen und in Zukunft dann diese Problem nicht haben. Aber wenn der Fragesteller in jede Falle stolpern will die es mit seinem Lösungsansatz (hier dbGo mit Access) gibt. Bitte sehr.

[p80286]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1222123)

Wenn man immer im voraus wüsste das der Fragestelle ein Tunnelblick hat und Hinweise auf Probleme die Rechts und Links neben seinen aktuellen Problem lauern ignoriert würde ich mir meine Zeit die ich kostenlos zur Verfügung sparen und solche Fragesteller liebend gerne ignorieren.

Sei nicht so streng, manchmal muß man mit solchen Vorgaben leben.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1222123)

Glücklicherweise gibt's auch genügen Fragestelle die Hinweise auf andere vorhandene Probleme/Schlechte Implementierung die sich mit der gestellten Frage zeigen gerne annehmen und in Zukunft dann diese Problem nicht haben. Aber wenn der Fragesteller in jede Falle stolpern will die es mit seinem Lösungsansatz (hier dbGo mit Access) gibt. Bitte sehr.

Im Prinzip :thumb::thumb:

Gruß
K-H

[Bernhard Geyer]

[OT]

Zitat:

Zitat von p80286 (Beitrag 1222125)

Sei nicht so streng, manchmal muß man mit solchen Vorgaben leben.

Manchmal muss ich mich aufregen (Auch wenn ich sonst hier ziemlich ruhig bin).
Hätte ich es gestern Abend noch geschrieben wären die Worte noch ganz anders geworden[/OT]