Dynamische Feldzuweisung

Hallo,

ich habe in einer Tabelle die Spalten 1 bis 12, die auch so heißen.
Mit einem Report möchte ich diese nun Dynamisch Füllen, d.h.
wenn die Berechnung für das Feld 8 ist (z.B. Monat 8 = August), schreibe das Ergebniss in das entsprechende Feld der Spalte 8.

Mir fällt aber nur der "Hart-Codierte" Weg ein, also z.B. über eine CASE Abfrage.

Hat ein er von Euch eine Idee?
Gibt es in der V4 bessere Optionen?
Gruß Michael

Da kommt das alte Problem mit den alten Versionen: Was du bräuchtest, sind die Record- bzw. FieldRefs. Du kannst dann mittels

Code:

Field := RecordRef.FIELD(FieldNo);

drauf zugreifen.
Ich weiß aber nicht, obs das in deiner Version schon gibt.

Danke für die Info,
das mit RecRef / FieldRef habe ich mir schon fast gedacht.

In der 2.6 gibt es das leider noch nicht
Kennt Ihr andere Lösungsansätze?
Gruß Mikka

Och komm, ein CASE für 12 Fälle ist ja noch so gerade überschaubar

Hi Mikka,

ich hoffe, jemand schreibt hier die ultimative Lösung wie man auch ohne RecRef / FieldRef in 2.60 eine Feldzuweisung aus einem String zusammensetzen kann, aber leider muss ich dir die Hoffnung etwas nehmen:

Ich hab mich mittlerweile ausgiebig damit beschäftigt und auch selbst bereits einen Beitrag in diesem Forum geöffnet. Muss dir leider sagen, dass wir voll aufgeschmissen sind, denn mit 2.60 scheint das einfach nicht funktionieren zu wollen! Das ist sowas von ärgerlich und so grausam von Navision!

Schade, wünsch dir trotzdem viel Erfolg. Schreib uns, wenn du doch noch ´ne Lösung findest.

Gruß

Mit einem technischen Upgrade auf die neueste Version lassen sich diese Probleme elegant und ohne allzuviel Aufwand lösen. Bei bestehendem Wartungsvertrag ist die neue Lizenz ja kostenlos.

@Natalie
Ja, 12 sind kein Problem, aber ich möchte demnächst mit 52 Wochen arbeiten

@Dune
Es gibt schon einen Beitrag, "Schande auf mein Haupt", ich habe danach gesucht und nichts gefunden.
Wenn ich etwas herausfinde, wird es natürlich auch hier stehen

@Rotsch
Das mit dem Upgrade schiebe ich schon sein Monaten vor mit her, wir haben die Lizenz schon ein paar Monate. Ich komme nur nicht dazu das Technische Upgrade zu machen

Gruß Mikka

Sorry Mikka, wenn ich deinen Thread "missbrauche".

@rotsch: was muss ich bei einem technischen update beachten, läuft alles ohne probleme weiter? Auch Individual-Programmierung?

@mikka
vielleicht ist ja auch dein Ansatz zu überdenken. Wenn du (später) 52 Wochen darstellen willst, würde ich die Tabelle nicht mit 52 Spalten definieren, sondern eher datum,wert. Da hast du auch kein Problem mit den Zugriffen.
Wenn du nicht unbedingt eine Tabelle brauchst, lassen sich evtl. die Daten in einem Array speichern, da hast du mit dynamischen Feldzugriffen auch in den "kleinen" Versionen kein Problem.

Gruß
Thomas

@rotsch: was muss ich bei einem technischen update beachten, läuft alles ohne probleme weiter? Auch Individual-Programmierung?

Bei einem technischen Upgrade werden nur die Clients (und bei einer nativen DB der Serverdienst) auf den neuesten Stand gebracht. Applikatorisch ändert sich in der Datenbank nichts. Die C/SIDE-Programme bleiben, wie sie sind.

In der Regel läuft ein tech. Upgrade ohne Probleme. Der erste Benutzer, der die DB mit dem neuen Client öffnet muss die Konvertierung der DB bestätigen. Dies ist dann in wenigen Augenblicken gemacht.

Vielleicht hat aber sonst jemand noch Erfahrungen in diesem Bereich gemacht und weiss von möglichen Problemen. Ich hatte bisher noch nie Schwierigkeiten mit tech. Upgrades (was aber nichts heissen will)

@rotsch
da MS öfters mal die Wordversionen und Outlookversionen ändert, hatte ich da schon öfter Probleme, dass sowohl das Wordmanagement und Outlookmanagement nicht mehr funktionierte, da muss man die neuen DLL's mühsam Trigger für Trigger wieder zuweisen.

Bei einem technischen Update von einer so "alten" Version auf die aktuelle könnte es eventuell notwendig sein, alle Objekte per F11 kompilieren zu lassen, da einige C/AL-Befehle zwar die gleiche Syntax haben, aber intern anders umgesetzt wurden.
Damit es nicht zu unerklärlichen Fehlermeldungen kommt, sollte man daher alle Objekte nach einem technischen Update erneut kompilieren.

@tba: Die Objekte (und somit die darin enthaltenen Automation-Variablen) zeigen doch weiterhin auf die vorhandenen Office-Bibliotheken, somit sollte das keine Probleme darstellen.
Problematisch wird es möglicherweise erst, wenn plötzlich ein neues Office-Paket installiert wird.

Problematisch wird es möglicherweise erst, wenn plötzlich ein neues Office-Paket installiert wird.

Das sehe ich auch so. Und sowas kann auch geschehen, ohne dass ein tech. Upgrade durchgeführt wird. Gerade mit Outlook hatte ich immer mal wieder Probleme mit der OLHandler.dll

@mikka
vielleicht ist ja auch dein Ansatz zu überdenken. Wenn du (später) 52 Wochen darstellen willst, würde ich die Tabelle nicht mit 52 Spalten definieren, sondern eher datum,wert. Da hast du auch kein Problem mit den Zugriffen.
Wenn du nicht unbedingt eine Tabelle brauchst, lassen sich evtl. die Daten in einem Array speichern, da hast du mit dynamischen Feldzugriffen auch in den "kleinen" Versionen kein Problem.

Ein Array geht leider nicht, da ich die Daten dauerhaft Speichern möchte.

-->Datum, Wert:
Du meist je Zeile ein Datum, einen Wert und mein Referenzfeld (z.B. Artikelnr.)?
Das hatte ich auch schon überlegt, aber verworfen, da die Daten in einem "nicht gerade idealen" Anzeige-/ Ausgabe-/ format vorliegen.
Ich werde nochmal darüber nachdenken, ob ich es doch so umsetzten kann / werde?!
Gruß Mikka

Wie wäre es, die Tabelle umzustricken?
Du benötigst nur noch zwei Felder: Einheit und Menge.
In die Einheit schreibst du z.B. deine 8 (August), die Menge ist selbstredend.
Über einen Filter auf die Einheit kannst du dann weiterhin Summen bilden.

@timo @rotsch
m.E. nach bringt Navision die OLHandler mit und wenn ich mich nicht irre, mit jeder Navisionversion eine andere, die sich dann mit dem technischen Update nicht verträgt.

Wie wäre es, die Tabelle umzustricken?
Du benötigst nur noch zwei Felder: Einheit und Menge.
In die Einheit schreibst du z.B. deine 8 (August), die Menge ist selbstredend.
Über einen Filter auf die Einheit kannst du dann weiterhin Summen bilden.

Das ist das was ich zuvor Beschrieben habe. (Nur ein wenig dürftig formuliert!)
Weitere Summen will ich nicht bilden, da dieses bereits die Informationen sind, die ich benötige.

Problem ist nur, das bei ca. 6000 Artikel und 52 Kalenderwochen ca. 312000 Zeilen enstehen im Jahr, die ich in geeigneter Form wiedergeben muss.
Ich habe mich entschieden dieses über eine Matrixform abzubilden.
(Mit der ich gerade "Kämpfe")

Vorab ersteimal *Danke*
Gruß Mikka