Nach MySQL Migration von 4.1 zu 5.6.12 Tabellen in Access abweichend sortiert

[Java-Jim]

Hallo,

ich habe mittels MySQL Workbench eine Datenbank nach 5.6.12 migriert und erlebe seitdem ein merkwürdiges Problem.
Per ODBC Treiber 5.1 greife ich von Access mittels verknüpfter Tabellen auf dem MySQL Server zu.
Wenn ich einfach eine Tabelle in der Datenblattansicht aufrufe, ist diese Tabelle nicht mehr nach dem Primärschlüssel FertID aufsteigend sortiert sondern nach dem Feld AplanId. Wenn ich die Tabelle mit z.B. HeidiSQL, mysql.exe oä. selektiere, wird die Tabelle so wie sie ist dargestellt. Also mit dem Autoinkrement Feld FertigungsID aufsteigend. Ich verwende dazu kein order by oder so sondern einfach select * from tblfertigung; mache ich das gleiche aus Access kommen die Daten neuerdings in einer abweichenden Reihenfolge. In Tabelleneigenschaft ist nach dem Laden sortieren=aus. Selbst wenn ich nach dem Feld sortiere stimmt die Reihenfolge, jedoch nur in der Datenblattansicht der Tabelle und nicht wenn ich eine Abfrage/Recordset darauf verwende.

Ich möchte nicht die Abfragen mit einem Sortierkriterium versehen, da der Programmierer in VBA an verschiedenen Stellen folgende Vorgehen einsetzt, welches nicht geändert werden sollte, da ich auch nicht weiß wo dies überall geschieht:
   open recordset, recordset.movelast, myFertID=recordset.FertID und so weiter...
Da der letzte Datensatz nun nicht mehr der mit der letzten FertigungsID ist sondern mit der letzten AplanID gibt es Fehler im Programm.

Wie kann es sein, dass auf einmal eine Sortierung geschieht?
Wie kann ich es bewerkstelligen, dass das erwartete Verhalten wieder eintritt ohne das ich überall was ändern muss?
Kann man möglicherweise an der Tabellendefinition am Server das Verhalten korrigieren?

Code (php) [Auswählen] Erweitern


CREATE TABLE `tblfertigung` (
`FertId` INT(10) NOT NULL AUTO_INCREMENT,
`ArtikelID` INT(10) NOT NULL DEFAULT '0',
`ArtikelNR` VARCHAR(255) NULL DEFAULT '0',
`AplanId` INT(10) UNSIGNED NOT NULL DEFAULT '0',
`Datum` DATETIME NULL DEFAULT NULL,
`FertDatum` DATETIME NULL DEFAULT NULL,
`Menge` INT(10) NULL DEFAULT '0',
`Prüfmenge` INT(10) NULL DEFAULT '0',
`Lastupdate` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`FertigungsNr` INT(10) UNSIGNED NULL DEFAULT '0',
`GesamtZeit` DECIMAL(15,4) NULL DEFAULT '0.0000',
`GesamtKosten` DECIMAL(15,4) NULL DEFAULT '0.0000',
`Kid` INT(10) UNSIGNED NULL DEFAULT '0',
`Erledigt` TINYINT(1) NULL DEFAULT '0',
`Fremd` TINYINT(1) NULL DEFAULT '0',
`Bezeichnung` VARCHAR(255) NULL DEFAULT NULL,
`Istmenge` DECIMAL(10,0) NULL DEFAULT '0',
`Start` DATETIME NULL DEFAULT NULL,
`Stop` DATETIME NULL DEFAULT NULL,
PRIMARY KEY (`FertId`),
INDEX `AplanId` (`AplanId`),
INDEX `ArtikelID` (`ArtikelID`),
INDEX `DatumIx` (`Datum`),
INDEX `FertNRIx` (`FertigungsNr`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=21444;


ein SELECT aus Access 2010

Code (html4strict) [Auswählen] Erweitern


FertId ArtikelID ArtikelNR AplanId Datum FertDatum Menge Prüfmenge Lastupdate FertigungsNr GesamtZeit GesamtKosten Kid Erledigt Fremd Bezeichnung Istmenge Start Stop
21383 20098 600748 20503 26.08.2013 6 0 10.07.2013 15:39:32 21383 0 0 200 0 0 Büchse SG-E 60/110 - Sonder 0 10.07.2013
21424 20126 Z-03595 20532 19.07.2013 4 0 16.07.2013 17:28:57 21424 0 0 288 0 0 A2 Welle D=30 L=90 0 16.07.2013
21436 20127 26042176 Bl 28 20533 09.08.2013 2 0 18.07.2013 10:39:04 21436 0 0 137 0 0 obere Flanschwelle GG komplett KSA / KSM 0 18.07.2013
21442 20129 Div 101 20534 19.07.2013 8 0 18.07.2013 15:30:22 21442 0 0 116 0 0 Spurhalter - Ansatzstück 0 18.07.2013


ein SELECT aus HeidiSQL auf dem Server

Code (html4strict) [Auswählen] Erweitern


"FertId" "ArtikelID" "ArtikelNR" "AplanId" "Datum" "FertDatum" "Menge" "Prüfmenge" "Lastupdate" "FertigungsNr" "GesamtZeit" "GesamtKosten" "Kid" "Erledigt" "Fremd" "Bezeichnung" "Istmenge" "Start" "Stop"
"21440" "12508" "211662" "12308" "2013-08-26 00:00:00" NULL "2" "0" "2013-07-18 10:41:14" "21440" "0,0000" "0,0000" "200" "0" "0" "Zwischenflansch Trockner / SGU SCC" "0" "2013-07-18 00:00:00" NULL
"21441" "13140" "212011" "12983" "2013-08-26 00:00:00" NULL "5" "0" "2013-07-18 10:52:04" "21441" "0,0000" "0,0000" "200" "0" "0" "Buchse - Lagerung unten Trockner / SGU SCC" "0" "2013-07-18 00:00:00" NULL
"21442" "20129" "Div 101" "20534" "2013-07-19 00:00:00" NULL "8" "0" "2013-07-18 15:30:22" "21442" "0,0000" "0,0000" "116" "0" "0" "Spurhalter - Ansatzstück" "0" "2013-07-18 00:00:00" NULL
"21443" "18913" "A-7153420" "19322" "2013-08-15 00:00:00" NULL "50" "0" "2013-07-19 14:26:32" "21443" "0,0000" "0,0000" "137" "0" "0" "Abdeckung Bumperbeschlag 3 flg." "0" "2013-07-19 00:00:00" NULL



[Java-Jim]

Ich habe grad mal einen Test mit Excel gemacht...
Per ODBC die Tabelle eingebunden und dort stimmt die Reihenfolge. Es scheint mal wieder an Access zu liegen...

[MzKlMu]

Hallo,
mit Excel kannst Du eine Datenbank nicht vergleichen. Die Reihenfolge von Datensätzen in Access Tabellen ist unbestimmt und nicht zwangsläufig immer gleich.
Die Reihenfolge der Anzeige von Datensätzen richtet sich nach dem Primärschlüssel und wenn weitere Felder indiziert sind wird das auch zu einem Lotteriespiel.
Es kann auch nach Löschaktionen und dem anschließend erforderlichen Komprimieren zu anderen Reihenfolgen der DS in der Tabelle kommen. Mit anderen Worten, die tatsächlich Reihenfolge wie die Datensätze in der Tabelle liegen kennt man gar nicht. Was Du siehst ist die Anzeige.
Ich bin auch der Auffassung, dass dieses Verhalten (zufällige DS Reihenfolge) in großen Datenbanken (MySQL) noch extremer ist, da man hier den Speicherplatz optimiert und neue Datensätze auf den Platz gelöschter Datensätze schiebt. Du siehst dann den neuen Datensatz am Schluss, aber in Wirklichkeit ist er mittendrin.
Wenn das bisher bei euch geklappt hat, so war das Zufall (oder Glück), die Migration hat die Datensätze neu geordnet (im Hintergrund) was zu den Problemen führt.
Daher sollte man niemals auf die Tabellen direkt zugreifen, sondern über gespeicherte Abfragen. Gespeicherte Abfragen sind auch im Regelfall schneller als der Zugriff auf die Tabellen direkt und effizienter was den Speicherplatz betrifft. Es wurde bereits beim Anlegen der DB der grundsätzliche Fehler gemacht und auf Abfragen verzichtet.

Um Dir die Arbeit einer Korrektur zu vereinfachen, kannst Du die Tabelle umbenennen und eine Abfrage erstellen mit der umbenannten Tabelle als Datenherkunft.
Diese Abfrage sortierst Du wie gewünscht und speicherst diese mit dem ursprünglichen Tabellennamen. Dann funktionieren auch open recordset, recordset.movelast, myFertID=recordset.FertID und so weiter wie gehabt. Gerade wegen dieser Befehle kommst Du nach meiner Auffassung um Abfragen nicht herum.