Access-o-Mania

Access-Forum (Deutsch/German) => Bericht => Thema gestartet von: vandekibi am Juli 24, 2012, 15:48:39

Titel: Datentypenkonflikt
Beitrag von: vandekibi am Juli 24, 2012, 15:48:39
Guten Tag

Da wir neue Bestimmungen haben "darf" ich die Lohnblätter umschreiben resp. neu gestalten. An sich ganz einfach......ABER

Bei uns läuft alles über die Mitarbeiternummer. In der Tabelle Personaldaten ist die Mitarbeiternummer als Text abgespeichert (Beispiel 11-02, 41-01 oder 33-09)

In der Personaleinsatzplanung werden die Mitarbeiternummern als Auswahlinstrument und somit als Zahl gespeichert.

Bisher war damit nie ein Problem.

Nun habe ich alles beieinander und müsste auf dem Bericht die Mitarbeiternummer mit dem passenden Mitarbeiter verknüpfen und da kommt der "Datentypenkonflikt im Ausdruck".

Auf den alten Lohnblättern, die genau gleich aufgebaut sind (ohne die nicht relevanten Aenderungen) funktionierte diese Zusammenführung einer Abfrage (Personaleinsatzplanung - Abfrage) und der Tabelle Personaldaten mit den Angaben ohne Probleme.

Ich vermute mal, dass ich mittlerweile den Wald vor lauter Bäumen nicht mehr sehe und wäre über etwas Hilfe sehr froh.

Danke
Titel: Re: Datentypenkonflikt
Beitrag von: DF6GL am Juli 24, 2012, 16:28:00
Hallo,

vermutlich benutzt Du die falschen Felder für die Verknüpfungen..

"In der Tabelle Personaldaten ist die Mitarbeiternummer als Text abgespeichert "

das kann ja sein, aber bei dieser Nummer (Feld) handelt es sich sehr vermutlich nicht um das Primärschlüsselfeld. In der Tabelle "Personaleinsatzplanung" ist (auch sehr wahrscheinlich) dieses Primärschlüsselfeld (bzw. der Wert) benutzt.

"müsste auf dem Bericht die Mitarbeiternummer mit dem passenden Mitarbeiter verknüpfen "

was heißt das? Soll das eine verknüpfende Abfrage für den Bericht sein?

Falls so, poste mal den SQL-String dieser Abfrage und beschreibe die Schlüsselfelder in den Tabellen.
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 24, 2012, 17:53:43
Hallo

Ich versuch es mal....

in der Beilage habe ich die Beziehungen der Abfrage (roter Kreis) reingestellt.

Der alte Bericht war ganz einfach und funktioniert bei gleichen Beziehungen immer noch. Alte Abfrage plus Name, Vorname, Adresse, PLZ und Ort aus den Personaldaten (Blau).

Und wenn ich herausgefunden habe, wass ein SQL-String ist, dann poste ich auch noch den.

Danke

Titel: Re: Datentypenkonflikt
Beitrag von: Jonny am Juli 24, 2012, 18:59:36
Hallo,
dein Beilage kann ich nicht sehen.
Was Franz meint ist die Abfrage als SQL-String.
- Abfrage im Entwurf öffnen.
- Ansicht SQL
dann hast du den String.

Aber ich vermute das Gleiche wie Franz.
Du verknüpfst die falschen Felder.

Gruß

Johann
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 24, 2012, 19:08:09
hallo

und schon wieder etwas gelernt  ;D

Hier die SQL

SELECT Personaleinsatzplanung.ID, Personaleinsatzplanung.[Einsatz Nummer], Personaleinsatzplanung.Personalnummer, Personaleinsatzplanung.DA, Personaleinsatzplanung.DE, DateDiff("n",[Personaleinsatzplanung.DA],[Personaleinsatzplanung.DE])/60 AS Rapport, Personaleinsatzplanung.Funktion, [Liste der Entschädigungen pro Einsatzfunktion].Stundenansatz, [Rapport]*[Stundenansatz] AS Lohn, Personaleinsatzplanung.[Fahrspesen pauschal], Personaleinsatzplanung.[Km Entschädigung], [Km Entschädigung]*0.8 AS [KM Geld], Personaleinsatzplanung.[Sonn-Feiertag], IIf([Sonn-Feiertag]=-1,[Rapport]-[Nachtschicht],0) AS [Sonn-Feiertage], [Sonn-Feiertage]*([Stundenansatz]*0.1) AS SFZuschlag, [Rechnung mit Nachtschicht].Nachtschicht, [Nachtschicht]*([Stundenansatz]*0.1) AS Nachtzuschlag, [Lohn]+[SFZuschlag]+[Nachtzuschlag] AS [Lohn vor Abzug]
FROM [Rechnung mit Nachtschicht] INNER JOIN ([Liste der Entschädigungen pro Einsatzfunktion] INNER JOIN Personaleinsatzplanung ON [Liste der Entschädigungen pro Einsatzfunktion].Einsatzfunktion = Personaleinsatzplanung.Funktion) ON [Rechnung mit Nachtschicht].[Einsatz Nummer] = Personaleinsatzplanung.[Einsatz Nummer];
Titel: Re: Datentypenkonflikt
Beitrag von: DF6GL am Juli 24, 2012, 20:39:59
Hallo,


offensichtlich fehlt überhaupt die Verknüpfung zur Tabelle "Personaldaten"....
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 24, 2012, 20:58:07
Hallo

versuche es nochmal mit dem Printscreen von den Beziehungen.

In der Abfrage brauche ich die PERSDATEN noch nicht - die kommen an sich erst im Bericht hinzu.

Merci

[Anhang gelöscht durch Administrator]
Titel: Re: Datentypenkonflikt
Beitrag von: MzKlMu am Juli 24, 2012, 21:09:37
Hallo,
also ich kann da nicht wirklich was erkennen.
Nur dass keine referentielle Integrität gesetzt ist, was schon mal bedenklich ist.
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 24, 2012, 21:22:52
Hallo

Nun ja, die referentielle Integrität weigert sich mit ethlichen Fehlermeldungen den Dienst anzutreten. Wird wohl die nächste Baustelle sein.

Titel: Re: Datentypenkonflikt
Beitrag von: MzKlMu am Juli 25, 2012, 08:14:13
Hallo,
ZitatWird wohl die nächste Baustelle sein.
Das solltest Du zur 1.Baustelle machen. Wenn keine RI geetzt werden kann, können Fehler im Aufbau und/oder in den Daten vorliegen. Das sollte behoben/geklärt werden, bevor Du weiter machst. Und der Datentypkonflikt kann auch mit falschen Beziehungsfeldern und damit auch mit RI zusammenhängen.

Was kommen denn für Fehlermeldungen?

Und wie gesagt, das Bild ist wenig hilfreich.
Titel: Re: Datentypenkonflikt
Beitrag von: DF6GL am Juli 25, 2012, 11:38:04
Hallo,

und zusätzlich:

"In der Abfrage brauche ich die PERSDATEN noch nicht - die kommen an sich erst im Bericht hinzu."

Wenn die Daten im Bericht "hinzu" kommen sollen, dann müssen die auch schon in der Abfrage enthalten sein (außer man "holt" die Daten im Bericht mit z. B. den Domänenaggregat-Funktionen (Dlookup(), DCount(), etc) aus den Tabellen).

Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 26, 2012, 00:44:09
Hallo

und wieder eine Nachtschicht......

Also die Fehlermeldung: siehe Beilage

Und zum Bericht: Bisher habe ich es immer so gemacht, dass in den Abfragen nur mit der Personalnummer gearbeitet wurde. Im Bericht habe ich dann die Personalnummer und den Namen, Vorname, Adresse zusammengeführt. Hat bisher immer funktioniert.





[Anhang gelöscht durch Administrator]
Titel: Re: Datentypenkonflikt
Beitrag von: DF6GL am Juli 26, 2012, 11:54:06
Hallo,

zur Fehlermeldung: hab ich anfänglich schon beschrieben...


"Im Bericht habe ich dann die Personalnummer und den Namen, Vorname, Adresse zusammengeführt."


???     Du sprichst in Rätseln...


Titel: Re: Datentypenkonflikt
Beitrag von: Jonny am Juli 26, 2012, 14:32:46
Hallo,
wenn es so ist wie ich vermute hast du eine Abfrage. Beim Erstellen vom Bericht nimmst du die Abfrage
und dazu die Tabelle der Personaldaten um Name etc. zu bekommen.

Lieg ich damit richtig hast du bei der Datenherkunft vom Bericht einen SQL-String erzeugt den du
bearbeiten musst.

Änderungen an der Abfrage bewirken dann nichts.

Wie gesagt ist eine Vermutung. Prüfe bitte was bei der DS-Herkunft vom Bericht steht.

Gruß

Johann
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 27, 2012, 12:25:41
Sorry für die Rätsel.

@Johann : Bingo. Genau so funktioniert der Bericht. Jetzt habe ich einfach das Problem, dass ich Dir ohne Probleme die Funktionsweise einer zeitgesteuerten Schalteinrichtung erklären kann aber keine Ahnung habe was eine DS-Herkunft ist.

Merci
Titel: Re: Datentypenkonflikt
Beitrag von: DF6GL am Juli 27, 2012, 17:26:59
Hallo,

die Eigenschaft "Datenherkunft" eines Formulares oder Berichtes beschreibt, wie der Name schon sagt, die Quelle der Daten, die in diesem Formular/Bericht verarbeitet/benutzt werden sollen.

Der Eintrag in dieser Eigenschaft kann entweder nur ein Tabellen-/Abfragename oder auch ein SQL-Statement (das einer gespeicherten Abfrage gleichkommt) sein.

Tipp:  Im Form/Berichtsentwurf den Cursor (Schreibmarke) in das Feld  "Datenherkunft" im Eigenschaftenfenster/Daten setzen und F1 drücken....
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 28, 2012, 01:54:38
Hallo

Etwas verstehe ich einfach nicht.......

Ich habe einen alten Bericht, der sich aus einer Abfrage und der Tabelle (Persdaten) zusammensetzt und ohne Probleme funktioniert. Wurde vor rund 3 Jahren zusammengeführt.

Versuche ich heute mit dem aktuellen Access den genau gleichen Bericht zu machen komme ich nicht über die Entwurfansicht hinaus. Dies alles bei genau den gleichen Verbindungen.

Titel: Re: Datentypenkonflikt
Beitrag von: DF6GL am Juli 28, 2012, 08:43:35
Hallo,

und ich versteh nicht, was Du hast und machst...


"der sich aus einer Abfrage und der Tabelle (Persdaten) zusammensetzt "



???
 Was steht in der Datenherkunft des Berichtes??




"mit dem aktuellen Access den genau gleichen Bericht zu machen.."  

Was ist "aktuelles Access" ? Welche VERSION ist das?


"komme ich nicht über die Entwurfansicht hinaus"

WARUM nicht?  Stürzt Access ab?  Wird der Bericht nicht gespeichert?   ??
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 28, 2012, 10:24:06
Guten Morgen

Also, folgendes Vorgehen:

Mit dem Bericht Assistenten wird die Abfrage (Lohnabrechnung Abfrage) und die Tabelle Persdaten zusammengeführt.
Nach dem Abschliessen erscheint die Fehlermeldung (Beilage). Dies obwohl ich auf diesem Computer der einzige Nutzer bin - nichts anderes offen haben.

Im Bericht Datenherkunft steht folgende Quellen:
SELECT [Lohnabrechnung Abfrage].[ID], [Lohnabrechnung Abfrage].[Einsatz Nummer], [Lohnabrechnung Abfrage].[Personalnummer], [Lohnabrechnung Abfrage].[DA], [Lohnabrechnung Abfrage].[DE], [Lohnabrechnung Abfrage].[Rapport], [Lohnabrechnung Abfrage].[Funktion], [Lohnabrechnung Abfrage].[Stundenansatz], [Lohnabrechnung Abfrage].[Lohn], [Lohnabrechnung Abfrage].[Fahrspesen pauschal], [Lohnabrechnung Abfrage].[Km Entschädigung], [Lohnabrechnung Abfrage].[KM Geld], [Lohnabrechnung Abfrage].[Sonn-Feiertag], [Lohnabrechnung Abfrage].[Sonn-Feiertage], [Lohnabrechnung Abfrage].[SFZuschlag], [Lohnabrechnung Abfrage].[Nachtschicht], [Lohnabrechnung Abfrage].[Nachtzuschlag], [Lohnabrechnung Abfrage].[Lohn vor Abzug], [PERSDATEN].[NAME], [PERSDATEN].[VORNAME], [PERSDATEN].[STRASSE], [PERSDATEN].[NUMMER], [PERSDATEN].[PLZ], [PERSDATEN].[ORT] FROM [Lohnabrechnung Abfrage] INNER JOIN PERSDATEN ON [Lohnabrechnung Abfrage].[Personalnummer] =[PERSDATEN].[Personal Nummer];

Im neuen Monatslohnblatt hat es zwei Gruppenebenen: erst die Personalnummer und anschliessend DA (im Monat)

Aktuell habe ich Access 2010

Die ersten Tabellen wurden mit Access 2003 erstellt. Die meisten Abfragen, Berichte und Formulare mit Access 2007.


Wenn ich im Entwurf auf Ansicht drücke, dann kommt die Fehlermeldung 2.
Speichern des Berichts "Monatslohn geht aber.


Hier noch die Datenherkunft eines Berichtes, der diese Probleme bei gleicher Verknüpfung nicht hat. Er wurde vor Jahren mit Access 2007 mit Hilfe des Bericht Assistenten erstellt.

SELECT Lohnberechnung.ID AS Lohnberechnung_ID, Lohnberechnung.[Einsatz Nummer], Lohnberechnung.Personalnummer, PERSDATEN.NAME, PERSDATEN.VORNAME, PERSDATEN.STRASSE, PERSDATEN.NUMMER, PERSDATEN.PLZ, PERSDATEN.ORT, Lohnberechnung.Funktion, Lohnberechnung.DA, Lohnberechnung.DE, Lohnberechnung.Rapport, Lohnberechnung.Stundenansatz, Lohnberechnung.Lohn, Lohnberechnung.[Fahrspesen pauschal], Lohnberechnung.[Km Entschädigung], PERSDATEN.ID AS PERSDATEN_ID FROM PERSDATEN INNER JOIN Lohnberechnung ON PERSDATEN.ID=Lohnberechnung.Personalnummer;

[Anhang gelöscht durch Administrator]
Titel: Re: Datentypenkonflikt
Beitrag von: MzKlMu am Juli 28, 2012, 10:37:41
Hallo,
die Verknüpfung ist nicht gleich.
Ein mal so:
...INNER JOIN PERSDATEN ON [Lohnabrechnung Abfrage].[Personalnummer] =[PERSDATEN].[Personal Nummer];
Und die 2. Abfrage so:
...INNER JOIN Lohnberechnung ON PERSDATEN.ID=Lohnberechnung.Personalnummer;

Die Benamsungen sind ein Chaos.

Mal ID, dann Personalnummer dann wieder Personal Nummer.

Soche unterschiedlichen Namen sind oft die Wurzel allen Übels, weil man völlig den Überblick verliert was was ist und von welcher Tabelle.
Titel: Re: Datentypenkonflikt
Beitrag von: DF6GL am Juli 28, 2012, 10:40:36
Hallo,

das sind doch keine "gleiche Verknüpfungen"...



INNER JOIN PERSDATEN ON [Lohnabrechnung Abfrage].[Personalnummer] =[PERSDATEN].[Personal Nummer];


PERSDATEN INNER JOIN Lohnberechnung ON PERSDATEN.ID=Lohnberechnung.Personalnummer;


Du musst nun mal herausfinden, über welche Felder verknüpft werden muss. Ich tippe mal auf "PERSDATEN.ID"


Damit sollte es so lauten:

SELECT [Lohnabrechnung Abfrage].[ID], [Lohnabrechnung Abfrage].[Einsatz Nummer], [Lohnabrechnung Abfrage].[Personalnummer], [Lohnabrechnung Abfrage].[DA], [Lohnabrechnung Abfrage].[DE], [Lohnabrechnung Abfrage].[Rapport], [Lohnabrechnung Abfrage].[Funktion], [Lohnabrechnung Abfrage].[Stundenansatz], [Lohnabrechnung Abfrage].[Lohn], [Lohnabrechnung Abfrage].[Fahrspesen pauschal], [Lohnabrechnung Abfrage].[Km Entschädigung], [Lohnabrechnung Abfrage].[KM Geld], [Lohnabrechnung Abfrage].[Sonn-Feiertag], [Lohnabrechnung Abfrage].[Sonn-Feiertage], [Lohnabrechnung Abfrage].[SFZuschlag], [Lohnabrechnung Abfrage].[Nachtschicht], [Lohnabrechnung Abfrage].[Nachtzuschlag], [Lohnabrechnung Abfrage].[Lohn vor Abzug], [PERSDATEN].[NAME], [PERSDATEN].[VORNAME], [PERSDATEN].[STRASSE], [PERSDATEN].[NUMMER], [PERSDATEN].[PLZ], [PERSDATEN].[ORT] FROM [Lohnabrechnung Abfrage] INNER JOIN PERSDATEN ON [Lohnabrechnung Abfrage].[Personalnummer] =[PERSDATEN].[ID];  
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 28, 2012, 12:44:57
hallo

Vielen Dank für die Tipps und die Geduld.......

Also die Beziehungen sehen aktuell so aus (Beilage 1 Beziehungen Persdaten)

Ändere ich auf Persdaten.ID so funktioniert es tatsächlich und ich kann den Bericht ansehen..............................aber es erscheint nicht die Personal Nr. sondern die ID -Nummer der Personalakte.(Beilage 2)

Damit kann ich aber im Moment leben und den Bericht so gestalten, dass die Personalnummer eben nicht erscheint -

Falls aber auch eine Lösung für dieses kleine Problem hat - immer nur her damit.

Hauptsache die Sache läuft und die Löhne können nächsten Monat nach dem neuen System ausbezahlt werden.

[Anhang gelöscht durch Administrator]
Titel: Re: Datentypenkonflikt
Beitrag von: DF6GL am Juli 28, 2012, 14:41:53
Hallo,

naja, das ist doch noch Einiges falsch.

Die Verbindungslinie muss zwischen Personaleinsatzplanung.Personalnummer und Persdaten.ID (und NICHT Persdaten.[Personal Nummer]) liegen.

Weiterhin muss das Berichtsfeld zur Anzeige der Personalnummer an das Tabellenfeld Persdaten.[Personal Nummer] gebunden sein.

Warum es in der Abfrage Personaleinsatzplanung UND Lohnabrechnung_Abfrage zugleich gibt, ist mir auch schleierhaft. (Wobei die Line von Lohnabrechnung_Abfrage.Personalnummer  auch an Persdaten.[Personal Nummer] gehen muss.)    Vermutlich kann Personaleinsatzplanung ganz aus der Abfrage entfernt werden.
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 29, 2012, 01:33:41
Hallo

also zu den Abfragen

Die haben sich so entwickelt, darum war beim alten Lohnblatt zwei Abfragen. War so eine Leiche im Keller und da sie nicht mehr stinkte lebte man eben damit.

Die Verbindung habe ich gemacht.

Und dann stehe ich ein wenig im Wald (wie in der vergangenen Tagen)

Wie kann ich das Bereichsfeld zur Anzeige der Personalnummer an das Tabellenfeld Persdaten.[Personal Nummer] binden?
Titel: Re: Datentypenkonflikt
Beitrag von: DF6GL am Juli 29, 2012, 08:51:54
Hallo,

indem Du

Personal Nummer

in die Eigenschaft "Steuerelementinhalt" des betroffenenen Textfeldes schreibst...

und vorher

[Persdaten].[Personal Nummer]

noch in die Select-Liste der Abfrage aufnimmst:

.
.
.
.... [PERSDATEN].[NAME],  [Persdaten].[Personal Nummer],  [PERSDATEN].[VORNAME], [PERSDATEN].[STRASSE], [PERSDATEN].[NUMMER], [PERSDATEN].[PLZ], [PERSDATEN].[ORT] FROM .....
Titel: Re: Datentypenkonflikt
Beitrag von: vandekibi am Juli 29, 2012, 10:59:07


Jetzt erscheint jede Schicht einers Mitarbeiters in der Abfrage 10 mal, was natürlich die Mitarbeiter in der Lohntüte freut aber die Firma unweigerlich ruiniert.

Im Bericht kommt nun der " Datentypenkonflikt im Kriterienausdruck" wieder.

Ich werde es nächste Woche noch einmal von Null an versuchen möchte mich aber für die Hilfe und Geduld bedanken.