[Gelöst]FlowFields in SQL Reporting Services abbilden

So, in der Zwischenzeit sind wir der Lösung des Problems (Nr. 1) ganz geringfügig näher gekommen.
Tabelle B hat als Code sowohl reine Zahlen ('123') als auch Buchstaben ('ABC');
In meinem View (der nicht richtig funktioniert) wird nicht EIN Datensatz angezeigt, sondern nur die, die A.Code = Buchstaben haben.
Füge ich also in A und B jeweils einen 'BCD' hinzu, so taucht der A-Datensatz mit 'BCD' ebenfalls in der Ergebnis menge auf (=2 Datensätze).
In meinem schon vorher funktionierenden Beispiel bereitet dies dagegen keine Probleme.

Und wir wissen: Die Tabelle 50016 im Rohzustand ohne unsere weiteren Anpassungen verursacht auch keinen Fehler.

Ergo: Der Fehler liegt irgendwo in unserer Individualprogrammierung.
Hat jemand eine Idee, wie Individualprogrammierung auf einem NAV-Objekt dafür sorgt, dass der SQL-Server nur noch nicht-nummerische Datensätze joint?

Wenn A nur eine Teilmenge von B hat und Du A INNER JOIN B machst, werden alle Datensätze aus A angezeigt. Wenn Du aber B INNER JOIN A machst verhält es sich genau umgekehrt. Sind denn alle drei Abfragen struktur-identisch oder weichen sie ab?

"Mein" Lookup-FlowField befindet sich in der Tabelle 50016. Es gibt aber keine Tabelle Namens Mandantenname$50016$0. Dein genanntes Beispiel habe ich aber gefunden.

Falls das jemand mitlesen sollte, der genausoviel "Ahnung" wie ich haben sollte, dann hier eine Aha-Aussage für euch:

Wenn ihr ein Sum-FlowField abfragen wollt (ohne es über ein SQL-Statement selber nachzubilden), dann ist eure Tabelle nicht die NAV-Tabelle, in der das FlowField angelegt ist (bei mir war das die Tabelle 50016, s.o), sondern die Tabelle, auf die euer FlowField schaut (z.B. Item Ledger Entry, Tabelle 32. --> Mandantenname$32$0).

Eigentlich logisch, aber für absolute Newbies in diesem Thema gar nicht so klar ...

So, dann noch ganz allgemein zum Thema JOIN:
Man sollte immer mit einem [LEFT/RIGHT/FULL] OUTER JOIN arbeiten, weil (wie auch glaub ich schon gesagt worden ist) ein INNER JOIN nur solche Datensätze hervor bringt, wo das Verknüpfungsfeld in beiden Tabellen gefüllt ist.

[Natalie]

So, zurück zu meinem Problem mit der Query, die zu wenig Datensätze zurück gibt, bzw. wo ich mal eine Fehlermeldung bekommen habe.

Das Schlüsselfeld meiner Tabelle, auf die ich verknüpfen muss, ist ein Code-20-Feld. Durch irgend eine unserer Anpassungen wurde im SQL-Server aus diesem Feld statt VARCHAR(20) ein sql_variant ...!
Dies erklärt, warum der Join nicht das gewünschte Ergebnis geliefert hat. Vater- und Sohnfeld müssen ja das gleiche Format haben.

Leider ist dieses Phänomen auch auf anderen Tabellen aufgetreten (z.B. Customer). Auf der Cronus-DB (SQL) ist dieses Feld VARCHAR(20).

So, jetzt muss in nur noch heraus finden, was um Himmels Willen dieses Feld konvertiert hat ....

Zuletzt geändert von Natalie am 8. Januar 2008 10:20, insgesamt 2-mal geändert.

Durch irgend eine unserer Anpassungen wurde im SQL-Server aus diesem Feld statt VARCHAR(20) ein PS, sql_variant ...!

Es gibt ein Property SQLDataType im Table Designer. War die Datenbank mal nativ und wurde auf SQL migriert?

Es gibt ein Property SQLDataType im Table Designer.

Wo finde ich das in Navision?

War die Datenbank mal nativ und wurde auf SQL migriert?

Nein, direkt von 5.0-Cronus aus programmiert.

Wo finde ich das in Navision?

In den Properties von CODE Feldern.

Wo finde ich das in Navision?

In den Properties von CODE Feldern.

DANKE!
Da steht tatsächlich Variant statt Varchar drin ....

Die goldene Nati geht heute an dich!!!

Edit: Das Feld wude früher mal auf Variant geändert, damit die Sortierung in der Form
'14'
'16'
'150'
statt findet.

Edit: Das Feld wude früher mal auf Variant geändert, damit die Sortierung in der Form
'14'
'16'
'150'
statt findet.

Die Sortierung ist analog zur nat. DB. Also doch Migration?

Nein, während der Entwicklung, allerdings während einer sehr frühen Stufe. Daher habe ich es zwischenzeitlich wieder vergessen.