Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

SQL-Migration (Anfüge- und Löschabfragen)

Begonnen von ellinho, Februar 23, 2012, 12:23:54

⏪ vorheriges - nächstes ⏩

ellinho

Hallo zusammen.

Ich möchte eine bestehende Access-Datenbank auf einen SQL Server migrieren. Dazu habe ich ein adp-Projekt erstellt und bereits alle Tabellen, Berichte, Formulare, Makros und Module migriert. Jetzt kommen die Abfragen dran. Diese wollte ich mit dem SSMA migrieren. Dabei stolpere ich über Anfüge- und Löschabfragen, die nicht migriert werden können. Muss ich die in SQL händisch neu erstellen, oder gibt es da eine andere Lösung ?
Vielen Dank für Eure Hilfe.

Gruß
Karsten

database

Hallo Karsten,

"Dabei stolpere ich über Anfüge- und Löschabfragen, die nicht migriert werden können"

...und wie äußert  sich SSMA dazu?
Funktionieren 'normale' Auswahlabfragen? - Diese werden ja wahrscheinlich zu Views konvertiert.

Könnte mir vorstellen, dass SSMA wärend der Migration aus deinen Aktionsabfragen kein Stored Procedures erzeugen kann.

ellinho

SSMA äußert sich so dazu, dass Löschabfragen und Anfügeabfragen nicht mit SQL kompatibel sind. Habe nun im adp-Projekt gespeicherte Prozeduren für die Abfragen erstellt. Diese funktionieren auch, allerdings erscheint trotzdem die Meldung (Die gespeicherte Prodezur wurde ausgeführt, gab aber keine Datensätze zurück). Zunächst einmal würde ich gerne wissen, ob ich die Prozeduren nun auf der richtigen Seite (im Access-Projekt oder in SQL) erstellt habe. Die Abfragen sollen nämlich in SQL auf dem Server und nicht von Access auf dem Client ausgeführt werden. Was mir noch aufgefallen ist : In Access habe ich keine Möglichkeit, Werte in Tabellen zu schreiben. Das geht nur direkt über das SQL Server Management Studio. Weiterhin werden einige Formulare nur in der Entwurfsansicht korrekt angezeigt, so dass ich momentan keine Möglichkeit habe, über Formulare Werte in die Tabellen zu schreiben. Liegt da irgendwo ein Berechtigungsproblem vor oder habe ich sonst irgendeinen Denkfehler ? Ich bin dankbar für jeden Tipp.

Gruß
Karsten

Josef P.

#3
Hallo!

ZitatDie Abfragen sollen nämlich in SQL auf dem Server und nicht von Access auf dem Client ausgeführt werden.
Wenn die Abfrage keine Access-eigenen Funktionen einsetzt, wird sogar in einer mdb die Access/Jet-SQL-Anweisung auf ODBC-verknüpfte Tabellen so gut wie möglich an den Server weitergereicht.  ... das wollte ich nur erwähnen, da es immer wieder Gerüchte gibt, dass Access-Abfragen nur am Client ausgeführt werden und dazu zuerst alle Daten aus der Tabelle geholt werden müssen. Dieses Gerücht ist aber einfach nur Quatsch. :)

Zu ADP: in einer ADP-Datei gibt es keine lokal gespeicherten Abfragen oder Tabellen. Das sind alles Sichten oder Prozeduren aus der MSSQL-Datenbank. Ich würde mir aber überlegen, den Client auf ADP umzustellen. Seit Access 2007 ist das ein nicht mehr besonders beachteter Zweig von Microsoft. (Das war meiner Meinung nach sowieso nur eine Werbemaßnahme um die Leute vom Jet-Backend zum SQL-Server zu locken und auf den SQL-Server einzuschränken, da kein anderes DBMS verwendbar ist. Einen besonderen Vorteil konnte ich für mich - im Vergleich zu einem mdb-Frontend - nie entdecken. Anm.: auch in einer mdb kann man den MSSQL-Server arbeiten lassen.)
Mein Tipp: Tabellen, Sichten, Prozeduren usw. ausgiebig im Server nutzen, aber das Frontend weiterhin als mdb/accdb-Datei verwenden. Das FE aber für den Zugriff auf den Server optimieren (komplexere SQL-Anweisungen über ADODB mit direkter Connection zum Server starten usw.)

mfg
Josef

ellinho

#4
Danke zunächst einmal für die Erläuterungen. Das hilft mir in meinem Verständnis weiter. Ich habe das Problem mit meinen Anfüge- und Löschabfragen bereits lösen können. Die werden in Makros integriert und funktionieren auch wunderbar. Allerdings suche ich in der SQL-Datenbank vergebens nach den Modulen. In einer Stored Procedure, die ich gerade erstellt habe, musste ich ein Modul einbringen. Allerdings ist dieses in der Stored Procedure in SQL rot markiert und bringt bei Ausführung den Fehler : "Falsche Syntax bei.....". Bei Ausführung der Prozedur in Access kommt der Fehler : "Arithmetischer Überlauffehler beim Konvertieren von varchar in den numeric-Datentyp". Jetzt weiß ich nicht, ob entweder das Modul gar nicht nach SQL migriert wurde, oder ob es nicht unter SQL läuft. Fehlermeldungen sind ja bekanntlich manchmal irreführend.
Hier mal der Code des Moduls :

Public Function AnzArbStdMA(VMDatumvon As Date, VMDatumbis As Date, strMAID As String) As Double
Dim aktTag As Date
For aktTag = VMDatumvon To VMDatumbis
AnzArbStdMA = AnzArbStdMA + MASollStunden(aktTag, strMAID)
Next
End Function

Mit dem Modul werden die Anzahl der zu leistenden Arbeitsstunden für einen Zeitraum (VMDatumvon bis VMDatumbis) berechnet.

Vielleicht hat jemand eine Idee, ob und wie der Code umzuschreiben ist.

Vielen Dank für Eure Hilfe.

Gruß
Karsten

Josef P.

#5
Der SQL-Server kann nicht auf den Code vom Frontend zugreifen.
Die gezeigte Funktion "AnzArbStdMA" könntest du bei Bedarf in eine Funktion des SQL-Server schreiben. Das musst du allerdings selbst machen (in T-SQL formulieren), so etwas wird kein Konvertierungs-Tool schaffen.

Nur als Beispiel (Luftcode):
create function schema.AnzArbStdMA(
   @VMDatumvon  DateTime,
   @VMDatumbis  DateTime,
   @MAID nvarchar(255)
)
returns float
AS
BEGIN
   DECLARE @AnzArbStd float
   SELECT
       @AnzArbStd = Sum(S.SollStunden)
   FROM
        TabelleMitSollDaten S
   WHERE
       S.MAID  = @MAID
       AND
       S.FeldFuerTag between @VMDatumvon and @VMDatumbis
   
   Return @AnzArbStd
END


ZitatMit dem Modul der Prozedur/Funktion werden die Anzahl der zu leistenden Arbeitsstunden für einen Zeitraum (VMDatumvon bis VMDatumbis) berechnet.
Wobei die Schleife vielleicht unnötig ist, falls man die Summe (wie im obigen Code gezeigt) per SQL aus der Tabelle auslesen kann.

mfg
Josef

ellinho

#6
Habe den Titel mal abgeändert...

Zunächst vielen Dank, Josef.

Jetzt sehe ich wenigstens mal, wie so eine SQL-Anweisung aufgebaut sein muss. Leider sind die Berechnungen, die angestellt werden müssen, viel komplizierter. Als Basis dient eine Sollstundenberechnung. Für jeden Mitarbeiter sind in den Stammdaten Sollstunden für jeden Wochentag hinterlegt, da vollkommen unterschiedlich gearbeitet wird....SollstdMo, SollstdDi, SollstdMi usw. Nun existiert in der ursprünglichen Access-Datenbank eine Sollstundenberechnung. Diese wird im Folgemonat für den Vormonat durchgeführt. Hier die Funktion :

Public Function MASollStunden(datDatum As Date, strMAID As String) As Double
Dim rst As DAO.Recordset
   Set rst = CurrentDb.OpenRecordset("select * from Mitarbeiter where Personalnummer='" & strMAID & "'", dbOpenSnapshot)
If Not Feiertag(datDatum) Then
   Select Case Weekday(datDatum)
   Case 1
   MASollStunden = Nz(rst!SollstdSo, 0)
   Case 2
   MASollStunden = Nz(rst!SollstdMo, 0)
   Case 3
   MASollStunden = Nz(rst!SollstdDi, 0)
   Case 4
   MASollStunden = Nz(rst!SollstdMi, 0)
   Case 5
   MASollStunden = Nz(rst!SollstdDo, 0)
   Case 6
   MASollStunden = Nz(rst!SollstdFr, 0)
   Case 7
   MASollStunden = Nz(rst!SollstdSa, 0)
   Case Else
   MASollStunden = 0
   End Select
End If

Um dabei alles zu berücksichtigen, existierte in der Datenbank eine Feiertagsberechnung :

Option Compare Database

Option Explicit
'// ----------------------------------------------------------------
'// Feiertagsberechnung nach dem Algorithmus von Carl Friedrich Gauß
'// ----------------------------------------------------------------
Type DtFeiertage
    Jahreszahl         As Long
    Ostern             As Date
    Neujahr            As Date
    Karfreitag         As Date
    Ostersonntag       As Date
    Ostermontag        As Date
    Maifeiertag        As Date
    ChrHimmelfahrt     As Date
    Pfingstsonntag     As Date
    Pfingstmontag      As Date
    Fronleichnam       As Date
    DtEinheit          As Date
    Allerheiligen      As Date
    Heiligabend        As Date
    Weihnachten1       As Date
    Weihnachten2       As Date
    Sylvester          As Date
End Type
 
Dim m_uDTF As DtFeiertage
 
 
Public Function Feiertag(mdatum As Date) As Boolean
 
  Dim Jahreszahl As Integer
  Dim mbol As Boolean
   
  Jahreszahl = DatePart("yyyy", mdatum)
   
  mbol = False

'// Als Refrenzdatum zunächst m_uDTF.Ostern berechnen
   If Not Ostern_berechnen(Jahreszahl) Then Exit Function
   
'// Neujahr setzen (fester Feiertag am 1. Januar)
   m_uDTF.Neujahr = DateSerial(Jahreszahl, 1, 1)
   If mdatum = m_uDTF.Neujahr Then mbol = True
   
'// Karfreitag berechnen (beweglicher Feiertag; 2 Tage vor Ostern)
   m_uDTF.Karfreitag = m_uDTF.Ostern - 2
   If mdatum = m_uDTF.Karfreitag Then mbol = True
 
'// Ostersonntag = m_uDTF.Ostern!
   m_uDTF.Ostersonntag = m_uDTF.Ostern
   If mdatum = m_uDTF.Ostersonntag Then mbol = True
 
'// Ostermontag berechnen (beweglicher Feiertag; 1 Tag nach Ostern)
   m_uDTF.Ostermontag = m_uDTF.Ostern + 1
   If mdatum = m_uDTF.Ostermontag Then mbol = True
 
'// Maifeiertag setzen (fester Feiertag am 1. Mai)
   m_uDTF.Maifeiertag = DateSerial(Jahreszahl, 5, 1)
   If mdatum = m_uDTF.Maifeiertag Then mbol = True
 
'// Christi Himmelfahrt berechnen (beweglicher Feiertag; 39 Tage nach Ostern)
   m_uDTF.ChrHimmelfahrt = m_uDTF.Ostern + 39
   If mdatum = m_uDTF.ChrHimmelfahrt Then mbol = True
 
'// Pfingstsonntag berechnen (beweglicher Feiertag; 49 Tage nach Ostern)
   m_uDTF.Pfingstsonntag = m_uDTF.Ostern + 49
   If mdatum = m_uDTF.Pfingstsonntag Then mbol = True
 
'// Pfingstmontag berechnen (beweglicher Feiertag; 50 Tage nach Ostern)
   m_uDTF.Pfingstmontag = m_uDTF.Ostern + 50
   If mdatum = m_uDTF.Pfingstmontag Then mbol = True
 
'// Fronleichnam berechnen (beweglicher Feiertag; 60 Tage nach Ostern)
   m_uDTF.Fronleichnam = m_uDTF.Ostern + 60
   If mdatum = m_uDTF.Fronleichnam Then mbol = True
 
'// Tag der deutschen Einheit setzen (fester Feiertag am 3. Oktober)
   m_uDTF.DtEinheit = DateSerial(Jahreszahl, 10, 3)
   If mdatum = m_uDTF.DtEinheit Then mbol = True
   
'// Allerheiligen setzen (fester Feiertag am 1. November)
   m_uDTF.Allerheiligen = DateSerial(Jahreszahl, 11, 1)
   If mdatum = m_uDTF.Allerheiligen Then mbol = True
 
'// Heiligabend setzen (fester 'Feiertag' am 24. Dezember)
   m_uDTF.Heiligabend = DateSerial(Jahreszahl, 12, 24)
   If mdatum = m_uDTF.Heiligabend Then mbol = True
 
'// Erster Weihnachtstag setzen (fester 'Feiertag' am 25. Dezember)
   m_uDTF.Weihnachten1 = DateSerial(Jahreszahl, 12, 25)
   If mdatum = m_uDTF.Weihnachten1 Then mbol = True
 
'// Zweiter Weihnachtstag setzen (fester 'Feiertag' am 26. Dezember)
   m_uDTF.Weihnachten2 = DateSerial(Jahreszahl, 12, 26)
   If mdatum = m_uDTF.Weihnachten2 Then mbol = True
 
'// Sylvester setzen (fester 'Feiertag' am 31. Dezember)
   m_uDTF.Sylvester = DateSerial(Jahreszahl, 12, 31)
   If mdatum = m_uDTF.Sylvester Then mbol = True
 
  Feiertag = mbol
 
End Function
 
Function Ostern_berechnen(ByVal lYear As Long) As Boolean
 
'// Berechnung mit Hilfe des Algorithmus von Gauß
   On Error GoTo Err_Ostern_berechnen
 
   Dim i1  As Integer
   Dim i2  As Integer
   Dim i3  As Integer
   Dim i4  As Integer
   Dim i5  As Integer
   Dim iTZ As Integer                            '// iTZ = Tageszahl
 
   i1 = lYear Mod 19                             '// Formel nach Gauß
   i2 = lYear Mod 4                              '// Werte für die Jahre
   i3 = lYear Mod 7                              '// 1900 - 2099
 
   i4 = (19 * i1 + 24) Mod 30
   i5 = (2 * i2 + 4 * i3 + 6 * i4 + 5) Mod 7
   iTZ = 22 + i4 + i5                            '// Ermittelt den Tag
   If iTZ > 31 Then                              '// März oder April
       iTZ = iTZ - 31                            '// Wenn April, dann - 31 Tage
       If iTZ = 26 Then iTZ = 19                 '// Wenn 26.4. dann 19.4.
       If (iTZ = 25 And i4 = 28 And i1 > 10) Then iTZ = 18
       m_uDTF.Ostern = DateSerial(lYear, 4, iTZ) '// Ostern im April
   Else
       m_uDTF.Ostern = DateSerial(lYear, 3, iTZ) '// Ostern im Maerz
   End If
   Ostern_berechnen = True
 
Exit_Ostern_berechnen:
   Exit Function
 
Err_Ostern_berechnen:
   Ostern_berechnen = False
   GoTo Exit_Ostern_berechnen
 
End Function

Wie man sieht, wird hier mit Datensätzen hantiert, die (mal abgesehen von SollstdMo, SollstdDi usw.) aus keiner Tabelle ausgelesen werden können . Deswegen ist es für mich so schwer verständlich, dies in SQL umzusetzen.

Die ursprünglich besprochene Funktion AnzArbStdMA sowie die Funktion AnzArbTageMA für die Berechnung der Arbeitstage zwischen Datum VMDatumvon und VMDatumbis sind reine Berechnungen für Abwesenheitszeiten, für die natürlich ebenfalls die Werte SollstdMo, SollstdDi usw. wichtig sind, denn steht für einen Mitarbeiter das Feld SollstdMo auf 0 und es wird ein Urlaubszeitraum von MO-FR eingetragen, darf die Summe natürlich nur 4 Urlaubstage betragen. Ich denke allerdings, dass ich mit der Funktion MASollstunden beginnen muss, da diese in VBA die Grundfunktion war. Sieht man übrigens auch an der Funktion AnzArbStdMA in meinem letzten Beitrag. Dort spielt die Funktion MASollstunden ebenfalls rein.

Ich erwarte hier nicht, dass mir jemand vollständige SQL-Funktionen liefert (schön wär's natürlich  :)). Allerdings wäre der eine oder andere Tipp sehr hilfreich. (Danke schon mal an Josef für das SQL-Beispiel). So komme ich dem Ziel näher.

Gruß
Karsten

UPDATE !!!

Bevor ich mir einen für die Berechnung der Feiertage abbreche, habe ich mal losgelegt und eine Tabelle "Feiertage" mit den Spalten "Datum" und "halber_ganzer_Tag" angelegt, da der 24. und 31.12. nur als halber Tag zählen. Für diese Tage habe ich in die Spalte als Wert 0,5 eingetragen, für alle anderen Datumswerte den Wert 1. Habe zunächst mal alle Feiertage bis Ende 2014 eingetragen. Desweiteren habe ich eine Sicht "FTage" erstellt, die diese Daten ausliest. Nun geht es weiter...

Josef P.

#7
Hallo!

Tipp: denke mehr in Tabellen und nicht in Prozeduren. ;-)

Beispiel Feiertagstabelle:
Ich nutzt z. B. in meinen Datenbanken eine Tabelle "Werkskalender" in der die Feiertage und Arbeitsfreien Tage markiert sind.
Damit kann ich ohne Aufwand die Werktage zwischen 2 Datumswerten ermitteln.

Für die Befüllung der Tabelle verwende ich eine Prozedur, die diese Werte pro Jahr berechnet. Außerdem können die "Zeitplaner" die Daten manuell ergänzen um z. B. einen Werksurlaub einzutagen.
Anm.: keine Angst vor der Datenmenge. Wenn die richtigen Felder indiziert sind sind Auswertungen auf diese Tabelle schneller als eine Berechnung per VBA-Code.

Diese Werkskalender-Tabelle ist bei mir eine von wenigen TAbellen die bewusst denormalisiert ist. Ich speichere in dieser TAbelle z. B. auch Felder für Wochentag, Kalenderwoche usw. ab, damit ich später per SQL z. B. alle Montage eines Zeitraums ermitteln kann.

mfg
Josef

MzKlMu

#8
Hallo,
anbei mal ein Beispiel mit einer von Josef vorgeschlagenen Hilfstabelle als Werkskalender.
Im Beispiel ist alles enthalten, auch das Anlegen der Tabelle selbst. Einen solchen Kalender kann man Jahresweise anlegen, oder auch gleich für die nächsten 20 Jahre, Feiertage und andere arbeitsfreie Tage werden dann wenn bekannt angehakt. Es fehlt in der Kalendertabelle noch die Kalenderwoche, wenn Bedarf, muss die noch ergänzt werden.
Im Formular 0- gibt es eine kleine Erläuterung.
Die Ermittlung der Arbeitstage zwischen 2 Datumswerten reduziert sich auf einen Einzeiler innerhalb einer Funktion:
Public Function fncArbeitstage(ADat As Date, EDat As Date) As Integer
   fncArbeitstage = DCount("*", "AlleArbeitstage", "clng(TDatum) >= " & CLng(ADat) & " and clng(TDatum) <=" & CLng(EDat))
End Function


Es gibt auch eine Funktion zur Ermittlung des nächsten Arbeitstages nach einem bestimmten Datum.
Schaue es Dir an.

[Anhang gelöscht durch Administrator]
Gruß Klaus

ellinho

#9
Hallo und Danke zunächst für das Beispiel.
Sieht auch gut aus...allerdings wird es, denke ich, für mein Vorhaben nicht passen. Hier mal kurz eine Erklärung, was da früher abgelaufen ist:

Für die Berechnung der Sollstunden gab es in der "alten" Access-Anwendung keine Eingabemaske (Anfangsdatum, Enddatum). Wie im früheren Beitrag an der Funktion MASollstunden zu erkennen, lief dort eine Schleife durch, die die fest eingetragenen Sollstunden der Mitarbeiter (SollstdMo, SollstdDi usw.) sowie die Feiertage des jeweiligen Vormonats berücksichtigte und so die Sollstunden errechnete. Wenn ich Anfang Februar den Januar berechnete, lief die Schleife also quasi alle Tage des Januars durch, prüfte, ob der Mitarbeiter an diesem Wochentag arbeitet (diese Werte standen ja in der Mitarbeitertabelle unter SollstdMo, SollstdDi usw.) , wenn ja, wurde noch geprüft, ob an diesem Wochentag ein Feiertag war, wenn nein, wurden die Sollstunden aus der Mitarbeitertabelle gelesen und für jeden einzelnen Tag des Monats addiert. Somit denke ich, dass die Lösung mit einer Tabelle "Feiertag", in der nur die Feiertage eingetragen sind, eine "schmalere" Lösung ist und ausreicht. Das Problem ist, wie gesagt, die Schleifenfunktion. Ich habe hier ein tolles Buch, in dem das Thema "Schleifen mit T-SQL" nur leider etwas dürftig beschrieben ist (in Verbindung mit WHILE), bin da auch am "basteln", bekomme allerdings noch nichts funktionsfähiges hin. Fortsetzung folgt... :)

MzKlMu

Hallo,
die Feiertagstabelle so wie Du sie hast, hast Du in meinem Beispiel mit dabei. Du musst nur eine Abfrage erstelle mit dem Kriterium -1 in der Spalte Feiertag Ja/Nei und schon hast Du die gleiche Feiertagstabelle wie Du.


Der Sinn der von Dir beschriebenen Schleife erschließt sich mir aber nicht, eigentlich sollte sich das über eine gruppierte Abfrage darstellen lassen.

Wobei ich jetzt aber den genauen Tabellenaufbau nicht kenne.
Was passiert eigentlich wenn ein Mitarbeiter wegen einer Terminarbeit mal Sonn- oder Feiertags arbeiten muss?
Gruß Klaus

ellinho

#11
Danke. Das hatte ich noch nicht gesehen. Stimmt.

Bezüglich Schleife oder gruppierter Abfrage...der Tabellenaufbau ist folgender :
Es existiert eine Tabelle Mitarbeiter, in der u.a. Personalnummer, sämtliche Stammdaten und die Felder SollstdMo bis SollstdSo vorhanden sind. Aus diesen Feldern muss ich über eine Funktion (Schleife oder wie auch immer) unter Berücksichtigung von Feiertagen und Abwesenheitstagen die Sollstunden für den Vormonat errechnen lassen. Die Berücksichtigung von Abwesenheitstagen hatte ich in der "alten" Access-Datenbank allerdings später über eine andere Funktion erledigt, da es an der Stelle noch einmal komplizierter wird. Da musste sich Access für monatsübergreifenden Urlaub die Datumswerte "umbasteln". Beispiel : Hatte ein Mitarbeiter vom 23.01. bis zum 03.02. Urlaub eingetragen und das aktuelle Systemdatum lag im Januar, wurden Anfangs- und Endwert so belassen, da im Januar der Dezember des Vorjahres bearbeitet wurde...das Datum also für den Bearbeitungszeitraum nicht relevant war. Lag das aktuelle Systemdatum im Februar, hat sich die Funktion das Enddatum auf 31.01. gesetzt, so das Access den Abwesenheitszeitraum vom 23.01. bis zum 31.01. berechnet hat. Systemdatum März : Anfangsdatum geändert auf 01.02. - Enddatum belassen auf 03.02..

Wenn ein Mitarbeiter wegen einer Terminarbeit mal Sonn- oder Feiertags arbeiten muss, werden diese Stunden übrigens als Zusatzstunden eingetragen. Dafür existiert eine gesonderte Tabelle.

Wie kann ich die Sollstundenberechnung mit einer gruppierten Abfrage hinbekommen ? Ich habe als Grundlage, wie gesagt, die Tabelle "Mitarbeiter", in der die Felder SollstdMo bis SollstdSo existieren, sowie die Tabelle "tblAlleTage", in der die Felder TDatum (für das Tagesdatum), Feiertag (Ja/Nein), halber Tag (Ja/Nein) für Heiligabend und Sylvester, die nur als halber Tag Urlaub zählen, sowie das Feld WT (Kennziffer des Wochentags) existieren. Ist das überhaupt möglich, ohne Schleife zu arbeiten?

Gruß
Karsten

MzKlMu

#12
Hallo,
wenn man Schleifen benötigt, ist das oft ein Hinweis auf ein falsches Datenmodell. Und das sehe ich hier auch so.
ZitatEs existiert eine Tabelle Mitarbeiter, in der u.a. Personalnummer, sämtliche Stammdaten und die Felder SollstdMo bis SollstdSo vorhanden sind.
Die Sollstunden haben in der Mitarbeitertabelle nichts zu suchen. Hier ist ein weiterer Normalisierungsschritt mit einer extra Tabelle erforderlich. Weiterhin wird eine eine Tabelle benötigt für die sieben Wochentage. Das ist einfach eine Tabelle mit 7 Datensätzen von 1-7 (Mo-So). Zwischen den Wochentagen und den Mitarbeitern liegt eine n:m Beziehung vor.
Die Sollstunden werden dann als Datensätze erfasst. Das sähe dann so aus:


MitarbeiterID   Wochentag   Sollstunden
      1           1              5
      1           2              4
      1           3              5
      1           4              5
      1           5              4
      1           6              5
      1           7              5
      2           1              5
      2           2              4
      2           3              5
usw.


Ein vollständige Normalisierung der Datenban wäre zunächst mal Vorraussetzung um Gruppieren zu können. Das ist schon mal nicht gegeben.

Gruß Klaus

ellinho

Wertvoller Tipp. Vielen vielen Dank. Gesagt getan. Sollstunden aus Tabelle "Mitarbeiter" rausgeschmissen. Tabelle "Sollstunden" angelegt (Felder Personalnummer, Wochentag, Sollstunden) genauso, wie beschrieben, Werte eingetragen). Wie gehe ich am besten weiter vor? Ich müsste ja zunächst mal aus der Tabelle "tblAlleTage" den Betrachtungszeitraum eingrenzen. Z.B. möchte ich nun die Sollstunden aller Mitarbeiter für Januar 2012 berechnen lassen. Soll ich die Eingrenzung des Zeitraums in einer gesonderten Funktion machen, oder kann man alles in eine gruppierte Abfrage packen? Ist mir an dieser Stelle noch nicht ganz klar. Sorry! ???

MzKlMu

Hallo,
Ist mir an dieser Stelle noch nicht ganz klar. Sorry! Mir auch noch nicht, auch sorry.  ;D

Ich habe zunächst mal nur an die Normalisierungsregeln gedacht, deren konsequente Einhaltung Grundvorraussetzung ist.
Ich muss jetzt auch erst mal noch nachdenken/probieren.
Gruß Klaus