Schlüsselfelder in verschiedenen Datentypen

22. Februar 2008 18:27

Guten Abend,

in unserer Navision SQL-Datenbank haben die Schlüsselfelder aus mehreren Tabellen oft verschiedene Datentypen.
Wenn ich in Access z.B. die Tabelle "Artikel" und "Verkaufspreise" nehme, kann ich diese nicht über die Artikelnummer verknüpfen.
In "Artikel" ist die Artikelnummer eine Zahl, in "Verkaufspreise" ein String/Text. Ich helfe mir nun mit Zwischenabfragen in denen ich aus den Textwerten Zahlen mache, aber schön ist das ja nicht.
Muss man das verstehen? Navision Logik oder schlecht programmiert?

Danke,
Christian

22. Februar 2008 20:16

Ich denke der Fehlergrund ist ein anderer. Kann es sein, dass ihr bei der Artikelnummer (Feld) die Eigenschaft SQL Data Type=Variant eingestellt habt?
Wenn ja, dann müsst ihr das in wirklich ALLEN Artikelnummer-Feldern nachziehen. Grundsätzlich aber ist - meiner Erfahrung nach - von einer Änderung dieses Feldes (also <> Standard) abzuraten, wenn Access im Spiel ist.

28. Mai 2008 12:01

Artikelnummer (Feld) die Eigenschaft SQL Data Type=Variant eingestellt habt?

Also ich habe den Fehler gerade noch einmal reproduziert.
Ich kann die Felder "No_" (Artikelnummer) der beiden Tabellen
[Item] und [Sales Line] nicht verknüpfen.

Data Type steht bei beiden in Navision auf Code.

In der Access Verknüpfung ist das Feld
in der Tabelle Item eine Zahl (Long Integer)
und in der Tabelle Sales Line ein String / Text.

Sehr umständlich, ich muss bei fast allen Abfragen eine Zwischenabfrage einbauen in der ich aus Kunden/Artikel Nummer/Zahl dann eine Zahl/Nummer mache :-(

28. Mai 2008 13:36

Gefragt habe ich nach der Eigenschaft des Navision(!)feldes "SQLDataType".
Dieser Type muss in den Feldern der beiden Tabellen, die du miteinander verknüpfen möchtest, identisch sein. Standardmäßig ist das Feld leer, also <Undefined>. Wenn es gefüllt ist, muss es in beiden Tabellen gleich gefüllt sein.

28. Mai 2008 15:50

wieso programmierst du das alles in Access? Nimm NAV und die Schlüssel passen alle.
Da gibt's auch keine Probleme mit den Null etc.

29. Mai 2008 09:13

Habe nochmal gesucht und nun in den properties den SQL Data Type gefunden.
Der ist tatsächlich unterschiedlich, einmal Integer, einmal <Undefined>
Ist beides die Artikelnummer, schlecht programmiert oder hat das einen speziellen Grund?

tba hat geschrieben:wieso programmierst du das alles in Access? Nimm NAV und die Schlüssel passen alle.
Da gibt's auch keine Probleme mit den Null etc.


Ich kann in NAV nicht programmieren. Finde das ganze auch sehr umständlich, in Access kann ich mir (von den schlecht definierten Data Types mal abgesehen) die benötigten Tabellen in einer Abfrage verknüfen und bei Bedarf auch eigene hinzufügen.
Ich habe bereits einige sehr umfangreiche Abfragen und Reports erstellt die von unserem Navision Partner mit dem 4 fachen Aufwand kalkuliert werden. Und ob das Ergebnis dann so perfekt ist, wage ich zu bezweifeln.
Für einen einfachen Aktualisierungslauf muss ja schon "ein Report angelegt werden". Nein danke dafür brauche ich in Access 12 Sekunden... :wink:

29. Mai 2008 10:46

Also standardmäßig steht der SQL-Data Type vom Feld "No." in Tabelle 27 "Item" auf "<undefined>". Wie Natalie schon sagte - entweder alles oder gar nichts. Ich kann auf dem SQL-Server auch nicht 2 verschiedene Datentypen problemlos miteinander verknüpfen, da sind Schwierigkeiten vorprogrammiert. Und Access ... naja :wink: ... reagiert bestenfalls merkwürdig.
Am besten verhaust du den, der an der Item-Tabelle gebastelt hat :-)

25. Juni 2008 17:19

Die Aussage von dem Programmierer ist folgende:

Alle Schlüsselfelder stehen auf undefiniert (string).

Lediglich für die Debitorennummer oder Artikelnummer wurde dies geändert auf integer damit die Sortierung korrekt ist (ansonsten 1 10 2 3 30..).

Eine Änderung von allen dieser Felder auf integer ist nicht möglich da dieser Datentyp schlechter für die Performance sein soll.

Gruß

26. Juni 2008 16:40

sternenstaub hat geschrieben:Eine Änderung von allen dieser Felder auf integer ist nicht möglich da dieser Datentyp schlechter für die Performance sein soll.


Ich werde langsam etwas ungläubig, würde mich freuen wenn die Aussage jemand bestätigen kann?

Danke,

Gruß