(Gelöst) Flowfield als InT

Hallo ich hab mal wieder ein Problem....
ICh habe eine Feld das ist von Type Int
und ein Flowfeld.
Das Interger Feld möchte ich jetzt immer addieren.

Wenn ich den Key und den Summindex hinzugefügt habe kriege ich folgende Fehlermeldung:

"Summfelder, die einem aktiven Schlüssel zugeorden sind, müssen vom Typ "Dezimalzahl" sein ; Das Feld ist:
Feld;Packet;
Tablle; Sales Shipment Header,
Summfelder; Packet


Kann man irgendwie diese Fehlermeldung umgehen. Ohne jetzt das feld in Decimal umzuändern. Weil das darf ich nicht.

Zuletzt geändert von 3ug3n am 24. August 2010 20:34, insgesamt 1-mal geändert.

Ein Flowfield kann man sowieso nicht als SumIndexField deklarieren, das macht also nichts . Du wirst einen anderen Weg finden müssen ...

Mach ich auch nicht ........
also nochmal...

Tabelle: Sales Header
Packet Integer //Soll gezählt werden
PacketFLOW Decimal //Ist flowField soll die Packete zählen

FlowField eintsellungen von PacketFLOW:
Methode: Sum
Table: Sales Shipment Header
Field: Packet
Table Filter: Order No.=FIELD(No.)


Tabelle: Sales Shipment Header
Key;

Key Order No.
SumIndexFields Packet



Und wenn ich das mit dem Schlüssel ausgewählt haben kommt dann der oben geschrieben Fehler.

Die SIFT funktioniert nur mit Decimalfeldern. Das war schon immer so und ist auch mit SQL-Server nicht anders.
http://msdn.microsoft.com/en-us/library/dd355336.aspx

Darf ich kurz OT werden und eine kleine Verständnisfrage stellen:

Also ich hab bisher noch nie in meinen Individualanpassungen SumIndexFelder deklariert und verwendet, aber zumindest hab ich es hoffentlich richtig verstanden:

http://msdn.microsoft.com/en-us/library/dd355344.aspx

=> wenn dort 3 Zeilen zum Aufsummieren wären, z.B. 300, 100, 400 und die SumIndizes würden lauten 600,700,1100 dann hätte SIFT den Vorteil, dass anstatt 300 + 100 + 400 zu rechnen man einfach 1100 - 300 = 800 sagt.

Soweit so gut, aber: NAV ist ja ein 32-bit System.

Damit kann SIFT max. 2 ^ 32 = 4.294.967.296 als Zahl speichern? Das sind 4 Billionen. Ob es Szenarien gibt, wo das nicht mehr ausreicht?
Wird es von NAV eine 64-bit Edition geben?

@Lord_british:

Nicht ganz richtig:
zu einem Sumindex gehört ja immer ein Index, und die entsprechenden Felder, die aufsummiert werden sollen. Da ein Schlüssel so ca. 250Bytes groß werden kann, wären das rein theoretisch 256^250 unterschiedliche Werte, was ausreichen dürfte

NAV rechnet nämlich die Differenz aus dem Wert, der zum höchsten passenden Schlüssel gehört und dem des niedrigsten passenden Schlüssel als Bewegung aus.

Gruß, Fiddi

@Lord_british:

Nicht ganz richtig:
zu einem Sumindex gehört ja immer ein Index, und die entsprechenden Felder, die aufsummiert werden sollen. Da ein Schlüssel so ca. 250Bytes groß werden kann, wären das rein theoretisch 256^250 unterschiedliche Werte, was ausreichen dürfte

NAV rechnet nämlich die Differenz aus dem Wert, der zum höchsten passenden Schlüssel gehört und dem des niedrigsten passenden Schlüssel als Bewegung aus.

Gruß, Fiddi

Das verstehe ich nicht.

Auch wenn es doof klingt, aber ich dachte NAV geht nach dem Algorithmus:

Setze Filter über einen Datensatzbereich,
Suche ersten und letzten gefilterten Datensatz (ich nenne den ersten n-ten, den letzten n + m - ten),
Schau nach welcher Wert in der Spalte namens SumIndex bei dem n+m -ten Datensatz steht
Schau nach welcher Wert in der Spalte namens SumIndex bei dem n-1 -ten Datensatz steht
Bilde die Differenz aus dem vor-ersten nachgeschauten und dem zweiten nachgeschauten Wert, d.h. Wert an der Stelle n+m minus Wert an der Stelle n-1.

Wo kommt nun dein Schlüssel mit 250 Byte ins Spiel? Schlüssel ist doch nur dazu da, um Datensätze nach 1 .. n Kriterien aufsteigend, absteigend zu sortieren?

Ich dachte immer, dass NAV bei allen Posten im Hintergrund die Summe speichert und wenn ich dann nen Filter setze und per FlowField was aufsummieren möchte, dann sagt NAV z.B. SumIndex-€uro-Wert / oder Stück-Wert / an der Stelle Artikelposten Lfd.Nr. XYZ (n+m -te Stelle) minus SumIndex-€uro-Wert an der Stelle Artikelposten Lfd.Nr. ABC (n - 1 -te Stelle) = Summe aller Nicht-SumIndex-€uro-Einzelwerte von n bis n+m -ter Stelle.

Und die Summensumme über alle Artikelposten kann durchaus die 4 Billionen sprengen?

edit: oder versteh ich SIFT total falsch? http://i.msdn.microsoft.com/dynimg/IC254339.gif

Denn in der Grafik ist der Filter über alle 50020er Datensätze. Aber zum Rechnen greift NAV auf den Datensatz, der VOR dem niedrigsten innerhalb des Filters liegt, damit er die Summe 300 kriegt. Dann greift NAV auf den höchsten Datensatz, aber der noch innerhalb des Filters liegt mit der Summe 1000.
Daraus bildet NAV die Differenz.

EDIT 2: wobei, wenn ich im Objektdesigner irgend eine Postentabelle öffne, seh ich nirgends ein Feld, wo die Summen gespeichert werden. Ist das ein Geheimfeld oder wo genau speichert NAV die Zwischensummen?

Hallo,

Damit kann SIFT max. 2 ^ 32 = 4.294.967.296 als Zahl speichern? Das sind 4 Billionen. Ob es Szenarien gibt, wo das nicht mehr ausreicht?
Wird es von NAV eine 64-bit Edition geben?

Das war eigentlich nur eine Antwort auf diese Aussage. Sumindex-Felder sind grundsätzlich Dezimalfelder, und enthalten die Summen der aus den zugehörigen Posten ermittelten Betrags- und Mengenfelder.

Dieses ganze Wissen ist allerdings beim SQL-Server mit NAV ab Version 5.0 Sp1 hinfällig . Hier werden keine SIFT- Tabellen (-Indexe) mehr erzeugt, sondern in den Views werden nur die Postenwerte referenziert. Der SQL-Server sorgt dann für die korrekte Aufsummierung. Siehe hier.

Gruß, Fiddi