Hallo Miteinander,
nach dem Umstellen von MySQL auf den SQL Server funktioniert nachfolgendes nicht mehr:
In einer DAO Transaktion werden verschiedene Deletes durchgeführt und anschließend neue Daten in die Tabellen eingefügt.
Bei einer Tabelle, deren Namen einen Umlaut enthält fünktioniert der Delete aberr nicht der Insert. (Edit mit Execute)
Um den Fehler besser einzugrenzen habe ich die SQL Statements per Debug.Print gedruckt und diese im SQL Editor ausgeführt.
Da trat der Fehler nicht auf.
Die Namen mit Umlauten habe ich in Klammern gesezt, das hat aber auch ncihts gebracht.
Es liegt folgender Fehler vor:
ODBC Insert on a linked table firmen_Töst_ID failed.
Fehlernummer 3155
Es ist momentan nicht möglich den Umlaut zu entfernen. Das wird sicher kommen, aber im Moment wäre das zuviel arbeit.
Es geht ja auch wenn ich es im SQL Editor mache.
Der verwendete ODBC Treiber ist der 17er. Die Tabellen sind verlinkt.
(Auch die Umstellung auf ADO, würde ich gerne erstmal vermeiden.
*Edit*
Die Tabelle ist in einer 1:1 Verknüpfung. Weiß jetzt nicht ob das wichtig ist.
(Es sind auch keine Englisch - Deutsch Konflikte an der Stelle vorhanden wie beim letzten mal)
Würde mich freuen wenn jemand eine Idee hat.
Vielen Dank für eure Unterstützung.
Viele Grüße
trekking
Also so wie es aussieht liegt es an der 1:1 Verknüpfung der Tabellen. SQL Server scheint das nicht in einer DAO Transaktion zuzulassen die beiden Tabellen mit einem INSERT zu befüllen. Nimmt man es aus der Transaktion ist es kein Problem. Was in meinem Fall allerdings nicht geht.
Also ist die Lösung alles auf ADO umzubauen. Was ich nun auch gemacht habe. Jetzt geht es.
Falls hierzu jemand noch weitere Infos hat, dann würde mich das sehr interessieren. Es überrascht mich etwas und ich habe auch keine Einstellung gefunden wie ich das verändern kann. Access und MYSQL sind an dieser Stelle nicht so zickig.
Danke fürs Kopfzerbrechen.
Viele Grüße
trekking
Zitat von: trekking am Oktober 27, 2024, 01:03:28Access und MYSQL sind an dieser Stelle nicht so zickig.
Vor MySql 8 war die standard Storage Engine für MySql
MyIsam. Diese unterstützt keine Referenzielle Integrität!
Hallo,
ich denke mal, daß DAO-Transaktionen eher ungeeignet sind für so einen Zweck. Erst mal die Doku dazu:
https://learn.microsoft.com/de-de/office/vba/access/concepts/data-access-objects/use-transactions-in-a-dao-recordset
Hier findet sich u.a.:
ZitatBeachten Sie, dass alle Transaktionen untereinander unsichtbar sind. Eine Transaktion kann also nicht sehen, inwiefern die Datenbank durch eine andere Transaktion aktualisiert wurde, bis für diese Transaktion ein Commit ausgeführt wird.
In einer Transaktion, die auf SQL Server ausgeführt wird, ist sowas nicht möglich. Wenn eine Transaktion gestartet wird, werden die betroffenen Ressourcen geblockt, so daß die anderen Transaktionen warten müssen, bis diese fertig ist.
DAO ist aber für alle möglichen Arten, auch gemischte, verwendbar, also glaube ich kaum, daß DAO hier eine solche Sperre quer über die verschiedenen Ressourcen (eine CSV-Datei, eine Excel-Datei, eine SQL Server View und eine Access-Tabelle in einer Abfrage etwa) einrichten kann oder, wenn nur SQL Server betroffen ist, dort eine SQL Server Transaction einleitet.
Ich würde Dir daher empfehlen, das ganze über eine Stored Procedure auf dem Server zu machen. Hier wird die Transaction dann garantiert von SQL Server durchgeführt und beendet, ohne Zwischenschritt zum Client.
Bei 1:1-Tabellen gibt es zu beachten, daß es keine Haupt- und Untertabelle gibt wie bei 1:n, daher ist es nicht immer ganz einfach, die richtige Reihenfolge zu finden, in der die Daten gelöscht werden müssen, ohne die referentielle Integrität zu verletzen. Das hängt dann auch von der Art der 1:1-Verbindung ab, die sowohl ein PK wie auch ein Unique Index sein kann.
Das ist ebenfalls wichtig beim INSERT. Je nach Methode muß man ggf. den Datensatz zuerst in einer "Untertabelle" einfügen, bevor man den zugehörigen in der Haupttabelle einfügt, während man bei 1:n natürlich immer zuerst den Hauptdatensatz einfügt und dann die n-Datensätze.
Gruß
Christian
@christianZitat von: Bitsqueezer am Oktober 27, 2024, 12:24:02In einer Transaktion, die auf SQL Server ausgeführt wird, ist sowas nicht möglich. Wenn eine Transaktion gestartet wird, werden die betroffenen Ressourcen geblockt, so daß die anderen Transaktionen warten müssen, bis diese fertig ist.
ob und was gesperrt wird, ist vom eingestelltem "ISOLATION LEVEL" abhängig. Deshalb sollte das mit DAO schon funktionieren, sonst hätte man schon öfter darüber etwas gelesen.
Hallo,
da der Fehler 3155 ein unspezifischer Fehler ist, könnte man eventuell mehr Hinweise mit der DAO Errorauflistung erhalten. Möglicherweise hat es aber auch etwas mit dem Problem von 1:1 Tabellen zu tun, was Christian beschrieben hat.
Gruß
Ulrich
Zitat von: trekking am Oktober 27, 2024, 01:03:28Also so wie es aussieht liegt es an der 1:1 Verknüpfung der Tabellen. SQL Server scheint das nicht in einer DAO Transaktion zuzulassen die beiden Tabellen mit einem INSERT zu befüllen.
Das erscheint mir nicht plausibel. Das sollte funktionieren, wenn du die Tabellen in der richtigen Reihenfolge befüllst. - SQL Server prüft Constraints sofort, nicht erst beim Commit einer Transaction. Das ist unabhängig von DAO/ADO/Sonstwas.
Zitat von: Bitsqueezer am Oktober 27, 2024, 12:24:02In einer Transaktion, die auf SQL Server ausgeführt wird, ist sowas nicht möglich.
"Sowas"?
Zitat von: Bitsqueezer am Oktober 27, 2024, 12:24:02DAO ist aber für alle möglichen Arten, auch gemischte, verwendbar, also glaube ich kaum, daß DAO hier eine solche Sperre quer über die verschiedenen Ressourcen (eine CSV-Datei, eine Excel-Datei, eine SQL Server View und eine Access-Tabelle in einer Abfrage etwa) einrichten kann oder, wenn nur SQL Server betroffen ist, dort eine SQL Server Transaction einleitet.
Doch, doch..
Wenn eine Datenquelle Transaktionen unterstützt und der Treiber das auch an Access meldet, dann kann man explizite Transaktionen über einen DAO.Workspace steuern.
Auch für remote ODBC Backends, wie SQL Server.
Auch über mehrere verschiedene Datenquellen hinweg; also z.B. wenn man innerhalb einer DAO-Transaktion eine Access-Tabelle und eine SQL-Server-Tabelle ändert. - Dazu, wie robust dieser Mechanismus ist, wenn während dem Commit ein Absturz/Netzwerkfehler/etc passiert, habe ich keine Erfahrung. Ich fürchte da kann durchaus noch Grütze passieren. It's complicated...
Erstmal vielen Dank an alle, auch wenn es doch etwas aufgrund der unterschiedlichen Meinungen verwirrend ist ;)
Auch schon wieder mit euch zu kommunizieren :)
@philEs ist InnoDB
Die Tabellen werden in der bisher logischen Reihenfolge befüllt. Aber was ist bei 1:1 die tatsächliche logische Reihenfolge? Bei MySQL und Access war es die Reihenfolge, die ich nun auch benutzt hatte.
Wenn die Tabellen ohne Transaktion eingelesen werden, funktioniert es. Mit der Transaktion nicht und genau an der Stelle wo die "kleinere" der beiden 1:1 Tabellen eingefügt wird. Also ist die Wahrscheinlichkeit, dass da der Fehler liegt sehr hoch. Da wäre ich bei Christian und bei Ulrich.
Allerdings hatte ich die Tabellen nicht vertauscht um zu erkunden ob es den Fehler dann auch gibt. Hatte ich nicht dran gedacht. Wohl weil es bisher keinen Grund dazu gab.
@Chrstian
Das mit der Transaction auf dem Server ist sicher der beste Weg. Allerdings habe ich in dem Stadium nicht die Zeit, das alles zu verlagern. Das wird sicher später kommen. Auf der alten MySQL Version war das nicht möglich, da 5.0 nicht mit Access in der Richtung kommniziert hatte. Auch nicht Views. Deshalb ist die Logik im Moment noch im FE. Wird sich nun aber nach und nach ändern, sobald alles umgezogen ist und läuft ;)
@UlrichKannst Du das mit dem "ISOLATION LEVEL" bitte genauer spezifizieren. Wo stelle ich da was ein?
Jetzt habe ich es erstmal auf ADO umgebaut und es läuft wie es soll und Stabil. Das war auch erstmal der schnellste Weg.
Vielen lieben Dank an euch udn schön wieder mit euch zu kommunizieren.
Viele Grüße
trekking
Hallo,
das mit ISOLATION LEVEL liest du besser in der Doku nach, weil ich das hier nur unvollständig wiedergeben könnte.
Neben dem SQL Anweisung "Set Transaction ISOLATION LEVEL" in TSQL geht das auch in ADO:
https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/isolationlevel-and-mode-properties-example-vb (https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/isolationlevel-and-mode-properties-example-vb)
Wie der in DAO einzustellen ist, kann ich die im Moment aber nicht sagen. Das es Session bezogen ist, wären die üblichen verdächtigen die Connection, das Workspace Object oder eine DBEngine Property, wo ich mal nachschauen würde. Möglicherweise auch eine Einstellung im ODBC Treiber.
Gruß
Ulrich
Danke Ulrich,
sorry, dass der Dank so lange gedauert hat. ;)