[gelöst] Typenkonvertierung?

Hallo zusammen,

ich möchte einen einfachen Filter auf einen bestimmten Inhalt eines Feldes einer anderen Tabelle setzen in einem Report.

Dazu schreibe ich folgendes:

Code:

Job.SETFILTER(Status,Job.Status::Quote);

Als Fehlermeldung erscheint folgendes:
Eine Typkonvertierung kann nicht durchgeführt werden, da eine der Seiten einen ungültigen Typ hat.
Text := Option

Was mache ich falsch?

Zuletzt geändert von misterelektro1981 am 21. Januar 2011 09:32, insgesamt 1-mal geändert.

Entweder

Code:

Job.SETFILTER(Status,'%1',Job.Status::Quote);

oder - besser -

Code:

Job.SETRANGE(Status,Job.Status::Quote);

Vielen Dank, worin liegt denn der Unterschied zwischen Setrang und Setfilter? Kann ich anstelle des Setfilter auch immer Setrange verwenden?

Du könntest eventuell in die C/Side-Hilfe schauen Und auch hierher.

SETRANGE ist performanter, aber kann nur immer einen Wert filtern (in einer Bedingung).

SETFILTER kann (auch komplexe) Filterbedinungen benutzen udn auswerten.

SETRANGE ist performanter, aber kann nur immer einen Wert filtern (in einer Bedingung).

Performanter gilt nur auf einer native DB. Und was meinst du mit "nur einem Wert filltern"?

Der Beweis, dass SETRANGE performanter als SETFILTER sei, ist noch nicht erbracht worden.
Fakt ist: SETRANGE ist simpler in der Verwendung, SETFILTER dafür flexibler.

Mit SETRANGE kann sehr einfach auf einen einzelnen Wert bzw. einen zusammenhängenden Bereich (Range) gefiltert werden.
SETFILTER erlaubt die Verwendung aller von NAV unterstützten Filterbedingungen, so wie sie auch von dem Anwender auf dem jeweiligen Feld gesetzt werden könnten.

Der Beweis, dass SETRANGE performanter als SETFILTER sei, ist noch nicht erbracht worden.
...

Dann stellt sich für mich die Frage, wer diese Behauptung in den Raum gestellt hat.
Mir wurde das auch nur gesagt, das setrange "günstiger" sei.

Gruß,
Jan

Der Beweis, dass SETRANGE performanter als SETFILTER sei, ist noch nicht erbracht worden.

Also ich kriege das auf meiner lokalen Native problemlos hin, dass ein Zugriff mit SetRange schneller ist (insofern der Cache noch leer ist).

Edit: Ok auf meiner jetzigen 5er ist auch kaum noch ein Unterschied. Auf der alten DB (vor Jahren) hatte ich andere Ergebnisse.

Nicht schlagen..... ich hatte mich zwischen FIND(-) und FINDFIRST, welches für SQL ist vertan.... Ihr habt ja alle recht

Aber ja Setfilter kann eben komplexe Filterbedingungen und Setrange eben nicht ;)

ich hatte mich zwischen FIND(-) und FINDFIRST, welches für SQL ist vertan

Was hat FIND(-) bzw. FINDFIRST mit SQL-Server zu tun? Bei Befehle sind für beide DBs zu nutzen. FINDSET spielt seine wahrscheinlich erst auf dem SQL-Server aus.

Gruß, Fiddi

Aber Find('-') ist für die native DB optimiert. FINDFIRST für SQL. Hierbei ist das Hauptaugenmerk auf die Performance zu legen.

Funktionieren tuen beide, jedoch im SQL anders. Schau dir über den SQL-Perfomance Analyser an wie die Abfragen gestaltet werden und wann ein LOCK gemacht wird.

Hier steht auch nochmal drin how to work with record variables.

Im Buch von Stryk wirds auch beschrieben welche Auswirkungen das ganze hat. Die Befehle FINDFIRST etc. wurden ja mit 5.0 eingeführt, wo es die SQL-Server Option gab. Es macht schon einen Unterschied wie ich die Befehle nutze.
Ein weiterer Punkt sind auch die auftretenden Tablelocks bei den Befehlen.

Hallo,

woher weißt du das der FIND('-') auf der Native Datenbank nicht die gleichen Auswirkungen hat wie unter SQL? Und ein FINDFIRST auf der Native DB nicht das gleiche macht wie unter SQL? Kennst du die Cache-Algorithmen der Native-DB?

Ein FINDFIRST kann auf der Native genau das gleiche tun, wie unter SQL nämlich nur einen Datensatz lesen, während der FIND('-') auch unter der Native mehrere Datensätze in den Cache lesen kann, damit ein REPEAT.. UNTIL NEXT schneller wird.


Gruß, Fiddi

Link nicht gelesen?

Hier wird die Funktionsweise auch nochmal aufgegriffen.

In den Schulungsunterlagen für 5.0 wirds ebenfalls behandelt.

Im Buch von Marc Brummel "Programming Dynamics NAV 2009" wird folgende Aussage getroffen:

S.358 ff

"Following are the various forms of FIND:
FIND('-'): Finds the first record in a table that satisfies the defined filter and current key. Generally not an efficient option for SQL Server as it reads a set of records when many times only a single record is needed.
FINDFIRST: Finds the first record in a table that satisfies the defined filter and defined key choice. Conceptually equivalent to the FIND('-') but much better for SQL Server as it reads a single record, not a set of records.
FIND('+'): Finds the last record in a table that satisfies the defined filter and defined key choice. Often not an efficient option for SQL Server as it reads a set of records when many times only a single record is needed. The exception is when a table is to be processed in reverse order. Then it is appropriate to use FIND('+') with SQL Server.
FINDLAST: Finds the last record in a table that satisfies the defined filter and current key. Conceptually equivalent to the FIND('+') but often much better for SQL Server as it reads a single record, not a set of records.
FINDSET: The efficient way to read a set of records from SQL Server for sequential forward processing. FINDSET allows defining the standard size of the read record cache as a setup parameter, but normally defaults to reading 50 records (table rows) for the first server call. The syntax includes two optional parameters: FINDSET([ForUpdate][, UpdateKey]). The first parameter controls whether or not the read is in preparation for an update and the second parameter........"


Wir weichen an dieser Stelle vom Topic ab...

Das von das von dir zitierte ist natürlich völlig korrekt, aber woher weißt du, das diese Befehle auf der Native nicht genau das gleiche tun, wie unter SQL?

Wie z.B. auch hier (stammt wohl ursprünglich von Jörg Stryk), wird überall nur auf die Auswirkungen auf den SQL-Server hingewiesen. Ob die Native- DB nicht genauso von den neuen Befehlen profitiert steht nirgends, oder etwa doch?

Wenn ich weiß was ich tue kann ein FIND('-') genauso performant sein, wie ein FINDFIRST,FINDLAST oder FINDSET. Die neuen Befehle erlauben es nur, etwas genauer zu spezifizieren was man an Daten haben will.
Wenn ich das richtig im Kopf habe, hat MS in der 2009er einige FINDs wieder auf die alten Befehle geändert.

Gruß, Fiddi